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Intellectual Property Rights 

IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards" , which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http : //www .etsi.org/ipr ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by ETSI Project Broadband Radio Access Networks (BRAN). 

The present document describes the extension of the basic specifications of Data Link Control (DLC) of HIPERLAN/2 
systems for home applications. Separate ETSI documents provide details on the system overview, the physical layer, the 
basic DLC layer functions, the convergence sub-layers and the conformance test requirements defined for 
HIPERLAN/2. 

The present document is part 4 of a multi-part deliverable covering the HIPERLAN Type 2; Data Link Control (DLC) 
Layer, as identified below: 

Part 1: "Basic Data Transport Functions". 

Part 2: "Radio Link Control sublayer". 

Part 3: "Extension for Business Environment". 

Part 4: "Extension for Home Environment". 



Introduction 

The present document specifies the first phase extension of basic Data Link Control (DLC) layer functions for home 
applications of the HIPERLAN/2 (H/2) system.The H/2 system is confined to the two lowest layers of the open systems 
interconnection (OSI) model, the physical and the data link control layer. An overall description of the H/2 system is 
given in TR 101 683 (see Bibliography). The PHY layer is described in TS 101 475 [3]. 

The basic DLC layer functions are specified in two different documents (TS 101 761-1 [1] and TS 101 761-2 [2]). 
Document TS 101 761-1 [1] describes Transport and Logical Channels, Error Control, MAC, and mapping between 
PHY and MAC of H/2 system. Document TS 101 761-2 [2] deals with Radio Link Control (RLC) protocols to control 
radio resources, terminal association and connection establishment. The inter-working with higher layers is handled by 
convergence layers (CLs) on top of the DLC layer. The common part of packet and cell based convergence layer are 
defined in TS 101 493-1 and TS 101 763-1 (see Bibliography), respectively. 
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1 Scope 

The present document specifies the extension of the basic DLC layer functions in TS 101 761-1 [1] and 
TS 101 761-2 [2] for direct mode operation in home environment. This DLC home extension specification gives first an 
overview of the H/2 home system concept. It then describes additional rules and elements to transport DM data over the 
channels introduced in TS 101 761-1 [1]. Forward Error Correction (FEC) is introduced in the DLC layer to achieve a 
much lower bit error rate for isochronous packet transport without ARQ. The present document also extends the RLC 
protocols in TS 101 761-2 [2] to support Constant Bit Rate (CBR) traffic by fixed slot allocation, to enable parameter 
negotiation for multicast connections, to enable association of multiple CLs for wireless terminals, and to enable direct 
link (DiL) Power Control. Furthermore, It describes some RLC protocols which are only specific for DM operation in 
home environment, such as DiL Link Quality Calibration, Dynamic CC Selection, and CC Responsibility Handover. 
Besides, a PIN and time-window based authentication key distribution protocol is specified for HIPERLAN2 Home 
Devices (H/2-HDs). The DM services can be used by the IEEE 1394 CL (TS 101 493-3-1 and TS 101 493-3-2 (see 
Bibliography)) for wireless bridging of different IEEE 1394 buses. 

The present document does not contain algorithms, which are only performed locally in a device, but describes rules and 
elements to transport data over the air interface. The goal is to provide interoperability between devices of different 
manufacturers. 

The present document does not address the requirements and technical characteristics for type approval and 
conformance testing. These are covered in a separate set of documents. 



2 References 

The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. 

• A non-specific reference to an ETS shall also be taken to refer to later versions published as an EN with the same 
number. 

[1] ETSI TS 101 761-1: "Broadband Radio Access Networks (BRAN); HIPERLAN Type 2; Data 

Link Control (DLC) Layer; Part 1: Basic Data Transport Functions". 

[2] ETSI TS 101 761-2: "Broadband Radio Access Networks (BRAN); HIPERLAN Type 2; Data 

Link Control (DLC) Layer; Part 2: Radio Link Control (RLC) sublayer". 

[3] ETSI TS 101 475: "Broadband Radio Access Networks (BRAN); HIPERLAN Type 2; Physical 

(PHY) Layer". 



3 Definitions, symbols and abbreviations 
3.1 Definitions 

For the purposes of the present document, the following definitions apply: 

Access Feedback Channel: transport channel where the results of access attempts made in the random access phase of 
the previous MAC frame is conveyed. 

Association Control Function: group of control functions on top of the RLC that is responsible for the handling of the 
association between WT and CC. 
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Association control CHannel: logical channel in uplink that conveys new association and re-association request 
messages. 

Access Point: term Access Point used in the basic specifications is replaced by the term Central Controller throughout 
the present document to reflect that in home environment multiple H/2 devices can act as the access point to a fixed 
network, whereas the whole H/2 network is still controlled by a single entity, the Central Controller. 

Basic WT: H/2 home device, which is able to associate with a CC and to communicate with the CC in the control plane 
and with other H/2 home devices in the user and control planes. A basic WT is unable to become the CC. 

Broadcast CHannel: transport channel that broadcasts control information. 

Broadcast Control Channel: logical channel that broadcasts control information which is relevant for the current MAC 
frame. 

CC-capable WT: H/2 home device, which can act either as a Central Controller, or as a basic WT. When it is acting as 
the CC with respect to the control plane, it supports all features of a basic WT. 

Central Controller: provides control functionality equivalent to that of an access point in TS 101 761-1 [1] and 
TS 101 761-2 [2] but is not necessarily attached to a fixed network. This term is used where the central controller 
functionality is embedded in a WT. 

Centralized Mode: in centralized mode, all data transmitted or received by a mobile terminal have to pass the 
centralized controller, even if the data exchange is between mobile terminals associated to the same centralized 
controller. 

DLC connection: HIPERLAN/2 DLC operation is connection oriented. A DLC connection carries user or control data 
and is identified by a DLC connection identifier. 

DLC User Connection: DLC user connection is uniquely identified by the DLC connection ID and the MAC ID of the 
mobile terminal in CM. In DM two MAC IDs are necessary. 

DLC User Connection Control: group of control functions on top of the RLC that is responsible for the handling of 
DLC user connections. 

Downlink phase: part of the Downlink transmission of a MAC Frame during which user and control data is transmitted 
from the access point or central controller to mobile terminals. The data transmitted can be user as well as control data 
in unicast, broadcast and multicast modus. 

Direct Mode: data exchanged between two WTs associated with the same CC takes place without passing but under 
control of the central controller. 

Direct link phase: part of a MAC frame that only contains the data exchanged directly between two WTs in a direct 
link. 

Encryption Function: function that is responsible for keeping user data and part of RLC signalling between WT and 
CC in centralized mode and between WTs in direct mode confidential. 

Error control: responsible for detection of transmission errors and, where appropriate, for the retransmissions. One 
error control instance is provided per DLC connection. 

Frame CHannel: transport channel that is broadcast and which carries the frame control channel. 

Frame Control Channel: logical channel that contains the information how the resources are allocated in the current 
MAC frame. Its content changes in general dynamically from frame to frame. 

H/2 Home Device: device which supports at least the mandatory features in the H/2 basic specifications 
TS 101 761-1 [1] and TS 101 761-2 [2] and the home extension features in the present document. There are two types of 
H/2 home devices: basic WT or CC-capable WT. This generic term is also used if no difference is made between the 
device acting as the CC and the devices acting as WTs. 

Logical channel: generic term for any distinct data path. A set of logical channel types is defined for different kinds of 
data transfer service as offered by MAC. Each logical channel type is defined by the type of information it carries. 
Logical channels can be considered to operate between logical connection end points. 
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MAC Frame: periodical structure in time that appears on the air interface and that determines the communication of 
HIPERLAN/2 devices. It consists of a sequence of traffic channels and its composition has to follow a number of rules. 

Mobile Terminal: the term Mobile Terminal used in the basic specifications is replaced by the term Wireless Terminal 
throughout the present document to reflect that in home environment not all H/2 terminals need to be mobile. 

Non HE-compliant Device: H/2 device, which meets the basic DLC specifications in [1] [2], but not the DLC HE 
specifiction in the present document. 

PDU train: sequence of transport channels delivered to the physical layer. 

PHY mode: PHY mode corresponds to a signal constellation (modulation alphabet) and a code rate combination. 

Random Access CHannel: logical channel in the uplink of the MAC frame in which the WTs can send signalling data 
for the DLC or the RLC 

Random CHannel: transport channel in the uplink of the MAC that carries the logical channels random access channel 
and association control channel. 

Random access Feedback CHannel: logical channel where the result of an access attempt made in the previous MAC 
frame is conveyed. 

Random Access Phase: period of the MAC Frame where any WT can try to access the system. The access to this phase 
is based on a contention scheme. 

Radio Link Control sublayer: control plane of the DLC, which contains control protocol that offers transport services 
for the RRC, ACF and DUCC. 

Radio Resource Control: group of control functions on top of the RLC that is responsible for the handling of radio 
resources. 

Resource grant: allocation of transmission resources by a central controller. 

Resource request: message from a terminal to a central controller in which the current buffer status is transmitted to 
request for transmission opportunities in the uplink or direct link phase. 

Subnet: smallest configuration in a H/2 home system, which is characterized by an active CC sending BCCH on a 
certain frequency. A subnet is created after a CC is selected and ready to accept association requests from other H/2- 
HDs. 

Transport Channel: basic element to construct PDU trains. Transport channels describe the message format. 
Uplink phase: part of the MAC frame in which data is transmitted from mobile terminals to a central controller. 
Wireless Terminal: H/2 home device, which is not acting as a central controller for a subnet. 

3.2 Symbols 

For the purposes of the present document, the following symbols apply: 

F P Probing Frame 

TScan Frequency Scanning Time (per frequency) 

T FS Frequency Switching Time 

P Probing Period 

g(x) Code Generator Polynomial 

p(x) Field Generator Polynomial 

3.3 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

ABIR ARQ Bandwidth Increase Request 

ACF Association Control Function 
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ACH 


Access feedback CHannel 


AP 


Access Point 


ARQ 


Automatic Repeat Request 


ARB 


ARQ feedback message request bit 


ASCH 


Association control CHannel 


BCCH 


Broadcast Control CHannel 


BCH 


Broadcast Channel 


BE 


Business Extension 


BER 


Bit Error Rate 


CC 


Central Controller 


CL 


Convergence Layer 


CM 


Centralized Mode 


CRC 


Cyclic Redundancy Code 


C-SAP 


Control Service Access Point 


DCCH 


Dedicated Control CHannel 


DES 


Data Encryption Standard 


DFS 


Dynamic Frequency Selection 


DiL 


Direct Link 


DL 


Downlink 


DLC 


Data Link Control 


DLCC 


DLC Connection 


DUC 


DLC User Connection 


DUCC 


DLC User Connection Control 


DM 


Direct Mode 


EC 


Error Control 


FCCH 


Frame Control CHannel 


FCH 


Frame Channel 


FEC 


Forward Error Correction 


FCA 


Fixed Capacity Agreement 


FSA 


Fixed Slot Allocation 


FSA-RG 


Fixed Slot Allocation Resource Grant 


H/2 


HIPERLAN type 2 


H/2-HD 


H/2 Home Device 


MD5 


Message Digest #5 


HE 


Home Environment 


HEE 


Home Environment Extension 


IE 


Information Element 


IV 


Initialization Vector 


LCCH 


Link Control CHannel 


LCH 


Long transport CHannel 


LSB 


Least Significant Bit 


MAC 


Medium Access Control 


MAC-ID 


MAC-Identifier 


MSB 


Most Significant Bit 


MT 


Mobile Terminal 


NET-ID 


NETwork-IDentifier 


NOP-ID 


Network OPerator IDentifier 


OFDM 


Orthogonal Frequency Division Multiplexin; 


PC 


Power Control 


PDU 


Protocol Data Unit 


RCH 


Random Channel 


RFCH 


Random access Feedback CHannel 


RLC 


Radio Link Control Protocol 


RG 


Resource Grant 


RR 


Resource Request 


RRC 


Radio Resource Control 


RSS 


Received Signal Strength 


RSS2 


RSS measured in Direct Mode 


SAP 


Service Access Point 


RBCH 


RLC Broadcast CHannel 
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SCH 


Short transport CHannel 


SSK 


Session Secret Key 


TS 


Technical Specification 


U-SAP 


User Service Access Point 


UBCH 


User Broadcast CHannel 


UDCH 


User Data Channel 


UL 


Uplink 


UMCH 


User Multicast CHannel 


WT 


Wireless Terminal 



4 Overview 

4.1 H/2 Home Network Architecture 

The H/2 home network is compliant to the ETSI/BRAN framework architecture, namely each H/2 device consists of the 
PHY, the DLC, and one or multiple CLs. The home environment specific DLC services are realized based upon the 
basic functions specified in TS 101 761-1 [1], TS 101 761-2 [2] and TS 101 475 [3], and the DLC HE functions 
specified in the present document. The application layer in a H/2 home device makes use of the DLC services through 
an application specific CL. In particular, the 1394 CL (TS 101 493-3-1 and TS 101 493-3-2 (see Bibliography)) is used 
to support IEEE 1394 based applications. 

4.1 .1 The single subnet model 

Unlike infrastructure based configuration, the H/2 home system is designed as an adhoc LAN, which can be put into 
operation in a plug-and-play manner. The H/2 home system utilizes the H/2 basic features in TS 101 761-1 [1] and 
TS 101 761-2 [2] by defining the following equivalence between the adhoc LAN configuration and the infrastructure 
based configuration: 

• A subnet in the adhoc LAN configuration is equivalent to a cell in the infrastructure based configuration; 

• A central controller in the adhoc LAN configuration is equivalent to the access point in the infrastructure based 
configuration. 

Thus, the smallest configuration in a H/2 home system consists of a single subnet. It is assumed that a single subnet is 
enough to cover near future applications in typical private homes. At each point in time only one H/2 WT can act as the 
CC in a subnet. 

A subnet is created when the CC starts to generate valid BCCH, and allows other devices to associate with the network. 
All devices of a subnet shall be synchronized to the frequency chosen by the CC, and access the channel using the MAC 
frame structure given in BCCH and FCCH by the CC. The selection of the CC is dynamic, and seamless handover of the 
Central Controller (CC) responsibility from one CC -capable WT to another is possible. 

To obtain a unified control framework for both infrastructure and adhoc modes of operation, the control plane is kept 
centralized for all general features in ad hoc mode. That means that only the CC can instruct a WT to do something. 
However, distributed control is also made possible for some home extension features by introducing logical control 
channels, which can be used for direct exchange of control messages between WTs. 

In the user plane, H/2 ad hoc mode makes extensive use of direct link user connections. This significantly improves the 
resource efficiency, since in a typical home environment most user traffic is of intra-cell nature. As in the infrastructure 
mode, the 8-bit MAC -ID is used to differentiate devices in a subnet, and the 6-bit DLCC-ID plus the source and 
destination MAC-IDs are used to differentiate connections between a pair of devices, or broadcast/multicast connections 
originating from any WT in ad hoc mode. 

The present document deals only with a single subnet model, in which each WT can listen to the CC. This ensures that 
the control plane functions specified in TS 101 761-1 [1] and TS 101 761-2 [2] are mostly reusable. For user plane, DM 
is used, provided that two WTs can reach each other directly. A link quality calibration process helps to track the 
connectivity between any two devices by measuring the associated RF link quality. The CC is used as a user data relay 
for a pair of WTs, if direct link between these two WTs is not possible. Even this user data relaying is performed during 
the direct link phase between the WTs and the CC. 
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The above single subnet model can be extended to support hidden terminals. In the context of the H/2 home system, 
hidden terminals are defined as terminals that cannot directly listen to the CC. However, hidden terminal support is 
beyond the scope of this release of the DLC HE specification. 

4.1 .2 The multiple subnets model 

If the capacity of a single subnet is insufficient, or the home is too large to be covered by a single subnet, multiple 
subnets operating on different frequencies can be applied. Each subnet is under the control of its own CC, and works 
independently of the other subnet(s). DFS is used to enable dynamic selection of the RF channel. Different subnets are 
differentiated by different AP-IDs, and all subnets belonging to the same owner shall use the same NET-ID. 

Different subnets can be interconnected either by a fixed network, or by H/2 bridging devices. Since user connections 
can be set up directly between any two WTs in a subnet, it is not necessary to use the CC to forward user traffic between 
different subnets. Potentially any device in a subnet can be configured as a bridging device to another subnet. A WT can 
associate with two overlapping subnets to become the bridging node between these subnets, provided it can be 
synchronized to the BCCHs of the two subnets alternatively. 

The inter-cell handover procedure specified in TS 101 761-2 [2] can be utilized to support mobility of H/2 home devices 
beyond the boundary of a single subnet. Inter-cell handover can be done either with or without fixed network support. 

Support for multiple subnets is beyond the scope of this release of the DLC HE specification. 

4.2 Service Types to be supported 

The H/2 DLC services are generic to support a variety of high speed multimedia applications. Features especially 
important for home environment include, but are not limited to: 

• Connection oriented high speed transmission for all application types; 

• Low delay, low delay jitter, and low bit error rate delivery of real time packets; 

• Isochronous and asynchronous services; 

• Acknowledged and unacknowledged asynchronous packet transfer; 

• Adhoc networking with QoS support; 

• Access to external networks (e.g. ADSL, DVB) from any H/2 home device; 

• Dynamic frequency selection and power control; 

• User-friendly security concept. 

These features are enabled by the present document together with TS 101 761-1 [1], TS 101 761-2 [2] and 
TS 101 475 [3]. In later releases, the H/2 home system intends to provide: 

• Mobility support; 

• Hidden terminal support; 

• Multiple subnets interconnect; 

• Directional antennas; 

• Add-on CL servers for different types of applications. 

For each type of applications, a convergence layer is required to convert the DLC SDU into a format which is accessible 
by the specific application layer, and vice versa. Support for Ethernet, IEEE 1394 and ATM based applications is 
specified in TS 101 493-1, TS 101 493-2, TS 101 493-3-1, TS 101 493-3-2, TS 101 763-1 and TS 101 763-2 (see 
Bibliography). Support for other applications, such as USB-based applications, can be added later on. 
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4.3 



Types of Devices supported 



For adhoc networking in home environment two, and only two H/2-HDs types are defined for the single subnet model: 

1) Basic WT 

2) CC-capableWT 

A basic WT is a user device that is able to associate with a CC and to communicate with the CC and other WTs in the 
control plane, and with other H/2-HDs in the user plane under the control of the CC. A basic WT consists of all DLC 
layer functions defined by the basic specs in TS 101 761-1 [1] and TS 101 761-2 [2] plus the functions defined in the 
present document. A basic WT shall support DM. 

A CC-capable WT can act either as a Central Controller, or as a basic WT. When it acts as the CC, it is capable of 
performing all control plane functions specified in TS 101 761-1 [1], TS 101 761-2 [2] and in the present document for 
the role of AP, or CC, respectively. Furthermore, for each supported CL all required CL functions at the AP side, or CC 
side, respectively, need to be implemented in the CC-capable WT. Support for handover functions in TS 101 761-2 [2] 
is optional for CC-capable WTs. A CC-capable WT acting as CC shall also be able to communicate with other WTs in 
the user plane as a basic WT. That means that it shall support all basic WT functions, additionally. 

The acting CC for a subnet is dynamically selected among all active CC-capable WTs. User interaction to prefer a 
special CC-capable WT to become the active CC is possible. Seamless handover of the CC responsibility from one 
CC-capable WT to another is also possible. 



H/2 home devices shall support all logical channels defined in subclause 5.1 and subclause 6.1 of TS 101 761-1 [1]. 
Implementation of direct link UDCH, LCCH, UBCH, UMCH, DCCH and RBCH are mandatory. The DiL UDCH and 
DiL LCCH shall be used for unicast user communication between any two H/2-HDs, and the associated link control, 
respectively. The DiL UBCH and DiL UMCH shall be used for user broadcast from any one H/2-HD to all other H/2- 
HDs supporting the same CL, and for user multicast from any one H/2-HD to a group of other H/2-HDs, respectively. 
DiL DCCH shall be used for RLC message exchange between any two H/2-HDs, or from a DM sender to a group of 
DM receivers in case of DiL multicast. DiL RBCH shall be used for distribution of RLC messages from any one H/2- 
HD to all other H/2-HDs. UL DCCH is used for the transmission of RLC messages from a WT to the CC, unicast DL 
DCCH for transmission of RLC messages from the CC to a particular WT, and DL RBCH is used for transmission of 
RLC messages from the CC to all WTs. 

In order to use DiL UBCH or DiL UMCH a WT shall perform the respective join procedure in TS 101 761-2 [2]. 

H/2-HDs shall also support downlink multicast using DL DCCH to send control messages from the CC to a group of 
WTs, what is not specified in TS 101 761-1 [1]. In this case, the multicast MAC-ID assigned during the multicast join 
procedure in [2] shall be used for downlink DCCH. 

NOTE: Unlike DiL DCCH, downlink DCCH is identified by a single MAC-ID. 

It is mandatory that all H/2-HDs use DiL UDCH, or DiL UMCH, or DiL UBCH for exchange of user packets with one 
or more other H/2-HD, even if the peer entity is the CC. A H/2-HD may use uplink or downlink UDCH/UMCH/UBCH 
to send or receive user packets, if the peer device is not subject to the home extension specification in the present 
document. 



5 



DM transmission and reception functions 



5.1 



Logical channels and their characteristics 
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5.2 Transport channels and their characteristics 

H/2 home devices shall support all transport channels defined in subclause 5.2 and subclause 6.2 of TS 101 761-1 [1]. 
Implementation of direct link LCH and SCH are mandatory. The LCH is allocated in the DiL phase to transport user 
data for the connections related to the DiL UDCH, DiL UBCH, and DiL UMCH, and long control packets for the 
connections related to the DiL DCCH and DiL RBCH. The SCH is allocated in the DiL phase to transport short control 
packets for the connections related to the DiL LCCH, DiL DCCH and DiL RBCH. 

Possible PHY modes for different transport channels are given in subclause 6.8.1 of TS 101 761-1 [1]. The PHY mode 
for LCH related to DiL UDCH, DiL UMCH, DiL UBCH and DiL DCCH is one of all possible PHY modes as defined 
in TS 101 475 [3]. The PHY mode for LCH related to DiL RBCH is set to the most robust one (BPSK Vi). The PHY 
mode for SCH related to DiL LCCH and DiL DCCH is set to BPSK Vi, or BPSK %, or QPSK The PHY mode for 
SCH related to DiL RBCH is set to the most robust one (BPSK Vi). 

5.3 Mapping between logical and transport channels 

The mapping between direct link logical and transport channels is given in subclause 5.3ofTS 101 761-1 [1]. Unlike 
centralized mode, the DiL LCCH does not include RR for direct link connections. The RRs for DiL LCH and DiL SCH 
shall be sent on the uplink DCCH using SCH, or RCH. 

5.4 Mapping between MAC frame and PHY frame 

The mapping between MAC frame and PHY frame is defined in subclause 6.9 of TS 101 761-1 [1]. 

One preamble shall be added at the beginning of each direct link PDU train. The preamble of the direct link PDU train 
shall have a length of 4 OFDM symbols, see TS 101 475 [3]. 

A direct link PDU train shall consist of all LCHs and SCHs belonging to the same pair of source and destination MAC- 
IDs. A set of SCHs and LCHs is granted for each DLCC by one RG. An WT shall receive not more than one direct link 
PDU train containing UDCHs, DCCHs, and LCCHs per MAC frame per source MAC -ID, i.e. all corresponding DLCCs 
shall be grouped in a single PDU train. It may receive the RBCH, UMCHs and UBCHs from the same sender in separate 
PDU trains. Since DCCH can also be used for downlink multicast in the HEE, a WT may receive a multicast downlink 
DCCH and a unicast downlink DCCH in separate PDU trains. 

A guard time between two consecutive DiL PDU trains shall always be inserted by the CC scheduler in order to cope 
with propagation delays, if the two PDU trains have different source MAC-IDs. A guard time may not be inserted if two 
subsequent PDU trains have the same source MAC-IDs. 

The duration of one OFDM symbol is equal to 4 |is if the long cyclic prefix is used, or 3,6 |is if the short cyclic prefix is 
used. Both long and short cyclic prefixes are mandatory to support by all H/2-HDs. The long cyclic prefix is used for all 
SCHs and LCHs carrying BCCH, FCCH, RFCH, ASCH, RBCH, DCCH, UBCH and corresponding LCCH, and UMCH 
without QoS negotiation by an explicit DUC setup procedure. 

The short cyclic prefix is the default value for all UDCH and UMCH connections, which are setup by an explicit DUC 
setup procedure. If during connection setup not otherwise negotiated, the short cyclic prefix is used for all SCHs and 
LCHs that carry UDCH and the corresponding LCCH, and UMCH with QoS negotiation. 

Within one PDU train SCH and LCH can use different cyclic prefix durations depending on what they carry, for 
example if they carry DCCH and UDCH. 

5.5 DLC Addressing for Home Environment 

The general DLC addressing concept in subclause 5.6 of TS 101 761-1 [1] applies to the H/2 home devices (home WT 
and CC-capable WT). The MAC-ID is assigned by the acting CC. When a subnet is created, the first active CC also 
internally assigns a MAC -ID to itself. 

For a given DM transmitter, the DiL DLCC-ID is unique for a particular receiver MAC-ID. 
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The NET-ID in the BCCH shall be regarded as the owner identifier of the H/2 home system. The NET-ID shall be a 
random number. During the installation process (see subclause 6.9), each new H/2-HD device to be installed shall store 
the NET-ID of its network, which is broadcast in the BCCH. Different subnets shall use the same NET-ID. The allowed 
range is to 959. 

When a subnet is to be created, the selected CC shall generate the AP-ID randomly. The device identifier, for example 
the IEEE EUI-64, of this CC shall be used as the seed of the random number generation. However, before the CC starts 
operation, it shall scan all possible frequencies and try to decode the associated BCCH to check if its randomly 
generated AP-ID is already used by another CC. This can be done in combination with the CC selection procedure in 
subclause 6.7. A new AP-ID shall be generated, if the old one is already occupied by another CC. 

In this release of the DLC HE TS no sectorized MAC Frame as described in subclause 5.4 of TS 101 761-1 [1] is 
considered for the CC. Therefore, Sector-ID = and # of sectors = 1 shall be set in the BCCH. 

The DiL RBCH is identified by the source MAC ID of the transmitting WT, destination MAC ID = and DLCC ID = 0. 

The DiL DCCH is identified by the source and destination MAC IDs of the concerned WTs and DLCC ID = 0. 

The DiL UMCH is identified by the source MAC ID of the transmitting WT, the destination multicast MAC ID (in the 
range of 224...254) and DLCC ID = 63. 

The DiL UBCH is identified by the source MAC ID of the transmitting WT, the destination broadcast MAC ID (in the 
range of 1...223) and DLCC ID = 63. 

For DiL UDCH, the destination MAC ID is used to identify an outgoing connection for the transmitting terminal and a 
source MAC ID identifies an incoming connection for the receiving terminal. It is permitted to have outgoing simplex 
connections with the same DLCC ID to different destination MAC IDs and to have incoming simplex connections with 
the same DLCC ID from different source MAC IDs. However, between a source and destination MAC ID pair, both 
directions of a bidirectional UDCH shall use the same DLCC ID. 

The DiL LCCH is identified by the source and destination MAC IDs of the concerned WTs and the DLCC ID of the 
related connection. 

The direct link UDCH, LCCH, UBCH, UMCH, DCCH and RBCH are announced in the FCH. 

5.6 Use of DiL logical channels 
5.6.1 Overview of the MAC frame 

The MAC frame structure is given in subclause 5.4 of TS 101 761-1 [1]. For H/2 home devices, the implementation of 
DiL phase is mandatory. Support of sectored antennas is beyond the scope of the present document. 

The basic MAC frame structure for H/2-HDs is shown in Figure 1 . Each MAC frame shall consist of the transport 
channels BCH, FCH, ACH and at least one RCH. If user data is to be transmitted, a DiL phase shall be provided. If 
downlink control data is to be transmitted (DL RBCH and/or DL DCCH), a DL phase shall be provided. If uplink 
control data is to be transmitted (UL DCCH), an UL phase shall be provided. A BCH, an ACH, a minimum length FCH 
and at least one RCH shall exist in every MAC frame. The duration of the BCH is fixed. The duration of the FCH, DL 
phase, DiL phase, UL phase and the number of RCHs are dynamically adapted by the CC depending on the current 
traffic situation. The order shall be: BCH - FCH - ACH - DL phase - DiL phase - UL phase - RCHs, from the point of 
view of a WT. 

NOTE: The specified order is from an WT's point of view. This means that a CC may e.g. have several DL, DiL, 
and UL phases and mix the phases, as long as the order is kept for each individual WT. 
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Figure 1 : Direct Mode MAC frame structure 



Detailed rules for the composition of MAC frames are given in subclause 6.3.2 of TS 101 761-1 [1]. 

5.6.2 Resource request and resource grant for direct link 

Resource Requests for direct link LCH and SCH are transmitted in RCH or in uplink DCCH using SCH with 
DLCC-ID = 0. No RR for DiL shall be sent in DiL LCCH. The rules for composing and transmitting RR for DiL are 
described in subclause 6.2.9.1.2 of TS 101 761-1 [1]. A RR for DiL is always related to a simplex connection whose 
direction is determined by the source and destination MAC -IDs in RRs. 

Resource Grants for direct link LCH and SCH are described in subclause 6.2.2.2 of TS 101 761-1 [1]. Like centralized 
mode, they are sent in FCCH. RG for DiL is always related to a simplex connection whose direction is determined by 
the source and destination MAC -IDs in RG. 



5.6.3 DiL LCCH for ARQ 

Direct link LCCH is defined in subclause 5.1.10 and subclause 6.2.9 of TS 101 761-1 [1]. It is only used for the ARQ 
protocol performed between two H/2-HDs in DM. The acknowledged mode of error control, the ARQ protocol, is 
described in subclause 6.4.2 of the TS 101 761-1 [1]. The ARQ protocol of HIPERLAN/2 is symmetric. The ARQ 
protocol is the same for two WTs in DM and for one WT and the CC in DM. ARQ feedback and the discard message 
for DiL have the same format as those for downlink. As in DL LCCH there is no ABIR in the ARQ feedback message in 
DiL LCCH. This is because the receiver of a DiL UDCH is not able to signal an increase in ARQ feedback bandwidth 
requirement to the CC by means of ARQ feedback messages in the DiL LCCH. Thus, the scheduler in the CC has to 
schedule sufficient DiL LCCH resources for ARQ feedback transmission. 



5.6.4 DiL DCCH for RLC 

Direct link DCCH is defined in subclause 5.1.6 and subclause 6.2.5 of TS 101 761-1 [1], and used for RLC message 
exchange between any two H/2-HDs in DM, or from a DM sender to a group of DM receivers. It is mapped to either 
DiL LCH or DiL SCH. This logical channel will be used, for example, by DiL power control and link quality 
calibration. 



5.6.5 DiL RBCH for RLC 

Direct link RBCH is defined in subclause 5.1.5 and subclause 6.2.4 of TS 101 761-1 [1], and used for RLC message 
broadcast from any one H/2-HD to all other H/2-HDs. It is mapped to either DiL LCH or DiL SCH. This logical channel 
will be used, for example, by link quality calibration. 



5.7 MAC protocol for DM 

In the Direct Mode the direction of logical channels is distributed as shown in Figure 2. 
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Figure 2: Direct Mode MAC protocol principle 

In Figure 2 WT 1 has a DiL connection to WT 2. As in centralized mode Resource Grants (RGs) are transmitted by the 
CC in the FCCH. Resources granted for DiL connections are related to DiL UDCH for User data and related to DiL 
LCCH for ARQ control messages (ARQ feedback and discard). PDUs in the DiL UDCH and discard PDUs in the DiL 
LCCH are directly transmitted from WT 1 to WT 2. ARQ feedback PDUs are directly transmitted from WT 2 to WT 1. 
The CC does not listen to the DiL UDCH and DiL LCCH if it is not a peer entity of the DiL connection. 

NOTE 1: The CC itself can act as a WT and thus it can be the source and/or destination of DiL connections. 

Resources for the DiL LCCH in case of ARQ feedback shall not be requested using RRs. The scheduling of sufficient 
resources for ARQ feedback is the task of the scheduler in the CC. 

Resources for the DiL LCCH for transmission of a discard message are requested with a RR for DiL. RRs for DiL are 
transmitted in the RCH or UL DCCH (DLCC-ID=0). 

Resource requests shall be used for DiL UDCH, DiL RBCH, DiL DCCH, DiL UMCH, DiL UBCH, and, in case of 
discard messages, also used for DiL LCCH. The rules for generating RR for DiL are described in subclause 6.2.9.1.2 of 
TS 101 761-1 [1]. The priority rules for using granted DiL SCH is described in subclause 6.2.2.2 of TS 101 761-1 [1]. 
The general MAC protocol described in subclause 6.3 of TS 101 761-1 [1] applies to H/2-HDs. 

NOTE 2: If the CC itself is requesting resources for DiL UDCH, DiL RBCH, DiL DCCH, DiL UMCH, DiL UBCH, 
and, in case of discard messages, for DiL LCCH, these resources are requested internally and no DiL RR 
is transmitted. The message for requesting resources internally in the CC is implementation-specific and 
outside the scope of the present document. 

5.8 EC protocol for DM 
5.8.1 General 

The EC protocol is described in subclause 6.2.2.2 of TS 101 761-1 [1]. The general aspects and the usage of EC in DM 
are described here. Additionally an FEC mode is supported. 

The CC and WT shall support four error control modes: 

1) Acknowledged mode; 

2) Repetition mode; 

3) Unacknowledged mode; 

4) FEC mode. 

DiL UDCHs for a certain connection shall either be sent in acknowledged mode, unacknowledged mode, or FEC mode. 
The negotiation during connection setup is defined by the corresponding DUC setup procedure. In case of the 
acknowledged mode, an implicit bidirectional DiL LCCH is set up. 
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DiL UMCH shall either use the unacknowledged mode or the FEC mode. 

DiL DCCH on LCH and DiL RBCH on LCH shall use the unacknowledged mode. 

DiL UBCHs shall either be sent in repetition mode or unacknowledged mode. In the case where multiple convergence 
layers are supported, the DiL UBCHs may use different error control modes. In the case of the repetition mode, an 
implicit unidirectional DiL LCCH is set up corresponding to a DiL UBCH. 

The figures below illustrate the possible setups. In these examples, the terms "transmitter" and "receiver" mean that the 
data transmission under consideration is from the transmitter to the receiver, although e.g. a connection using the DiL 
UDCH may be bidirectional. The RR message control flow is not considered here. 

Figure 3 illustrates the situation in the case of the acknowledged mode. A corresponding DiL LCCH is available which 
is used for ARQ feedback messages from the receiver to the transmitter and for discard messages from the transmitter to 
the receiver. 



Transmitter 



DiL 
UDCH 



DiL 
LCCH 



Receiver 



DiL 
LCCH 



DiL 
UDCH 



Figure 3: Illustration of the data and control flow in acknowledged mode 



Figure 4 illustrates the situation in the case of the repetition mode. In this case, an implicit unidirectional DiL LCCH for 
discard messages from the transmitter to the receiver is available. 




Figure 4: Illustration of the data and control flow in repetition mode 



Figure 5 illustrates the situation in the case of the unacknowledged mode. The data flows only from the transmitter to the 
receiver, no control data flow for ARQ feedback or discard messages is allowed. 
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Figure 5: Illustration of the data and control flow in unacknowledged mode 
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Figure 6 illustrates the situation in the case of the FEC mode. The data flows only from the transmitter to the receiver, 
no control data flow for ARQ feedback or discard messages is allowed. 
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Figure 6: Illustration of the data and control flow in FEC mode 



5.8.2 Error Control (EC) protocol for the acknowledged mode 

The acknowledged mode uses an ARQ protocol and is described in subclause 6.4.2 of TS 101 761-1 [1]. Most parts of 
the ARQ procedures of the transmitter and receiver are the same for CM and DM. Some special treatments for the direct 
link connections are summarized below. 

5.8.2.1 Handling of Dynamic ARQ bandwidth allocation for DM 

The number of SCHs available for ARQ feedback messages may change from MAC frame to MAC frame. Therefore the 
number of bitmap blocks that can be signalled in a frame changes dynamically, as determined by the CC scheduler. 

In CM the destination of UL ARQ feedback is the CC and thus the CC scheduler. Therefore, it is possible to signal 
increased ARQ feedback capacity needs by setting the ABIR bit to 1 in the UL ARQ feedback message. In DM the 
destination of DiL ARQ feedback is the peer WT and not the CC scheduler. Therefore, the ABIR bit is not available for 
the direct link. 

NOTE: The calculation of the amount of extra SCH capacity granted by the scheduler in the CC is out of the 
scope of the present document. 

5.8.2.2 Setting of the ARB in the RR for DiL 

In the case of a WT as a transmitter which is completely stopped (e.g. it has new LCHs to transmit but transmission is 
suspended by flow control or due to a stalled window), the WT may send a RR for DiL with #LCH=0 and ARB=1. 
Upon reception of such a RR for DiL, the CC scheduler should allocate appropriate resources for the receiving WT to 
transmit ARQ feedback messages. This allows the transmitter to inform the CC scheduler that it does not get sufficient 
feedback from the receiver. 

5.8.2.3 Receiver actions in case of insufficient ARQ feedback resources 
(informative) 

If the receiver detects that it does not get enough resources granted for ARQ feedback transmission, it may perform the 
following action (informative): 

• The receiver may request a more robust PHY mode for this specific connection, by setting a more robust PHY 
mode in a RR for this DiL connection. The #LCH and #SCH shall be set to zero, if no resources are to be 
requested. With a more robust PHY mode the number of reception errors may be decreased and thus the amount 
of ARQ feedback to signal negative acknowledgement. The amount of necessary CumAcks is not affected by the 
PHY mode setting. 

In DM a Receiver cannot signal directly to the CC scheduler that the ARQ feedback resources are insufficient (see 
subclause 5.8.2.1). 
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5.8.2.4 Transmitter actions in case of insufficient ARQ feedback resources 
(informative) 

If the transmitter in DM is stopped, which means that within the transmitters window or flow control (FC) limitation, 
neither unacknowledged nor negatively acknowledged nor new LCHs are to be transmitted due to lack of ARQ feedback 
even if the transmitter buffer is not empty, the transmitter may set ARB in the DiL RR as described in subclause 5.8.2.2. 

If the transmitter in DM is not stopped, it is not allowed to use ARB=1 and #LCH=0 to signal to the CC scheduler that it 
wishes to have more frequent ARQ feedback. 

5.8.2.5 Scheduling of sufficient ARQ feedback resources (informative) 

The CC scheduler shall schedule sufficient resources for ARQ feedback. The definition of sufficient resources and the 
scheduling algorithm is outside the scope of the present document. Following informative text is given to indicate the 
parameters which influence the need for ARQ feedback: 

• The minimum necessary ARQ feedback resources are given by the number of transmitted (scheduled) UDCH and 
the negotiated ARQ window size. At least one LCCH for ARQ feedback has to be scheduled if as many UDCH 
have been scheduled as the size of the ARQ window. This minimum number is far too low for proper operation. 

• The average PDU error rate influences the number of necessary ARQ feedback messages. As this number is not 
known to the CC scheduler, an estimation has to be made. A worst case assumption is 10%, as if Link Adaptation 
in the Receiver works properly, the Receiver asks for a more robust PHY mode if the PDU error rate exceeds 
10%. Proper operation of the ARQ protocol with an average PDU error rate of more than 10% is unlikely. 

• In order to limit the delay, the CC scheduler shall take into account the last time it has scheduled a DiL LCCH for 
ARQ feedback. The time between ARQ feedback signalling influences the total ARQ delay. 

• If the receiver requests a more robust PHY mode the CC scheduler may check whether it had scheduled sufficient 
resources for ARQ feedback. By scheduling more resources for ARQ feedback the Receiver may decide to ask 
for the former PHY mode again, if the reason for asking for a more robust PHY mode has been insufficient 
resources for ARQ feedback (see subclause 5.8.2.2). 

In order to improve the system performance the CC scheduler shall spend spare resources for ARQ feedback, if 
possible. 

5.8.3 EC protocol for the repetition and unacknowledged mode 

The EC protocol for the repetition mode and the unacknowledged mode is described in subclauses 6.4.3 and 6.4.4 of 
TS 101 761-1 [1], respectively. 

There are no differences between DM and CM for the EC protocol for the repetition mode and the unacknowledged 
mode. 

5.8.4 EC protocol for the FEC mode 
5.8.4.1 Principles 

When setting up a DiL UDCH or UMCH, a H/2-HD can determine if the DLC FEC mode shall be applied to this 
connection. When the FEC mode is selected, both acknowledged mode and unacknowledged mode are no longer 
possible for this connection. 

The DLC FEC scheme is based on a Reed-Solomon (RS) block code working on a multiple LCH-PDUs. For 8-bit 
symbols, the block length of the mother code shall be 2 A 8-1 = 255 bytes. To achieve an error correction capability of 8 
bytes per block, 16 bytes of redundancy shall be computed per block, leaving up to 239 bytes for protected data; hence, 
the mother code is a RS(255, 239) code. Out of these 239 bytes only 200 bytes shall be utilized by the DLC FEC, the 
rest is padding bytes which shall be only needed for computation but shall not be transmitted. The shortened code is 
referred to as a RS(216,200) code. 
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To suit the DLC FEC scheme, an additional UDCH message format is described which takes into account the specific 
information added by the FEC. DLC SDUs shall be concatenated in groups of 4 resulting in 200 bytes of protected data, 
as explained in subclause 5.8.4.3. 

The performance of the FEC scheme is further enhanced by the insertion of a convolutional interleaver with a depth of 
12 DLC PDUs. 

NOTE: In DLC FEC mode, the packet error rate may be more affected by the error rate of RR and/or RG for the 
particular connection than by the residual error probability of the FEC scheme itself. In this case, fixed 
slot allocation as presented in subclause 6.6.1 could be a means to avoid this limitation. 

5.8.4.2 UDCH message format 

The non-ARQ mode is mainly intended to be used for the UDCH channel. The basic format of such a message is defined 
in the DLC basic TS (Table 1 and Table 2): 



Table 1 : Content of the UDCH with CRC 



Name 


Length (bits) 


Purpose 


PDU type 


2 


See Table 2 


SN 


10 


Sequence number (provided by EC function) 


Payload 


49.5 x 8 


Payload field, i.e. DLC SDU 


CRC 


24 


CRC-24 checksum 


Total: 


54x8 





Table 2: LCH Type field 



PDU type 


Purpose 


00 


Normal DLC PDU (carries UDCH, DCCH and RBCH) 


01 


Dummy LCH 


10 


Future use 


11 


Future use 



In case the DLC FEC is used, the UDCH message format is as shown in Table 3. 



Table 3: Content of the UDCH with FEC 



Name 


Length (bits) 


Purpose 


PDU type 


2 


See Table 2 


Sync 


2 


Sync bits needed by FEC function 


Payload 


49.5 x 8 


Payload field (DLC SDU) 


FEC 


32 


One quarter of the RS redundancy 


Total: 


54x8 
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8 7 


6 5 


4 3 2 1 


1 


PDU type 


Sync 


MSB 


2 






3 


Payload 


4 


5 



50 


1 


51 


FEC 


52 




53 




54 





Figure 7: UDCH transfer syntax with FEC 
5.8.4.3 RS word generation 

Every RS word is constructed from data of 4 LCH PDUs of 54 bytes. An RS word shall be obtained from 4 consecutive 
payload fields of 49.5 bytes each, originating from the upper layer, or generated by the DLC in case of dummy RS 
words. 

The PDU type shall be correctly set according to the Table 2, depending on the nature of the payload. If the payload is 
generated by the DLC as dummy, the PDU type for dummy LCH, which is 01, shall be used. 

In FEC mode, dummy LCH PDUs shall not be discarded, but shall be passed to the deinterleaver. 

The sync field is set according to Table 4. As can be seen, one sync field out of four is inverted from 00 to 11. 



Table 4: LCH Sync field 



Sync field 


Purpose 


11 


PDU#1 


00 


PDU #2, #3 and #4 
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50 bytes 



< 



PDUType 


Sync 


DLCSDU 


(2 bits) 


(2 bits) 


(48 bytes and 12 bits) 



200 bytes 



PDU-T S Payload PDU-T S Payload PDU-T S Payload PDU-T S Payload 



RS (2 16, 200) 



t 

216 bytes 



< 



> 



PDU-T 


S 


Payload 


FEC 



PDU-T 


S 


Payload 


FEC 



PDU-T 


S 


Payload 


FEC 



Figure 8: RS word generation 



The 4 blocks of 50 bytes, are concatenated to form a 200-byte block, where each 50 byte block consists of the 2-bit 
PDU type, the 2-bit Sync field in front of the 49.5 byte DLC SDU each, 39 zero bytes shall be padded before these 200 
bytes and the obtained 239 bytes are fed to the RS(255,239) Reed-Solomon code with the following properties: 

• Code Generator Polynomial: g(x) = (x+|a° )(x+|a' )... (x+|i 15 ), where |i = 02 H ex 

• Field Generator Polynomial: p(x) = x 8 + x 4 + x 3 + x 2 + 1 

The 39 zero bytes shall be discarded after computation of the RS code word and shall not be transmitted over the air 
interface. 

The redundancy of 16 bytes per RS(255, 239) is split into 4 packets of 4 bytes each which are inserted at the end of each 
DLC PDU according to Table 5. 



Table 5: Redundancy addressing within a RS word 



Redundancy 
bytes 


#1 


#2 


#3 


#4 


#5 


#6 


#7 


#8 


#9 


#10 


#11 


#12 


#13 


#14 


#15 


#16 


PDU 


#1 


#1 


#1 


#1 


#2 


#2 


#2 


#2 


#3 


#3 


#3 


#3 


#4 


#4 


#4 


#4 


Octet in the 
PDU 


#51 


#52 


#53 


#54 


#51 


#52 


#53 


#54 


#51 


#52 


#53 


#54 


#51 


#52 


#53 


#54 



5.8.4.4 Dummy LCH PDU generation 

In the basic DLC TS 101 761-1 [1], the DLC can insert dummy PDUs by setting the PDU type value to 01. The content 
of the dummy payload is not specified. 

However, in case the DLC FEC mode is used, the Sync field shall always be correctly set according to the rule given 
above, where every fourth Sync field is inverted from 00 to 11, cf. Table 4. The value of the other bits of the dummy 
PDUs is not specified. 

At connection release, the sender shall ensure that always a multiple of four PDUs are transmitted over the air. If this is 
not achievable by the user PDUs alone, the sender shall generate up to 3 dummy PDUs to complete the transmission of a 
multiple of 4 PDUs over the air. 
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During the connection the sender may also generate as many dummy PDUs as necessary to fill multiple of 4 PDUs 
within one MAC frame. 

5.8.4.5 Interleaver and deinterleaver 

A Forney type convolutional interleaver with 3 branches is inserted after the RS output. The octets #1, #4,..., #52 of 
each LCH PDU shall be sent to branch #1, octets #2, #5,..., #53 to branch #2 and the other to branch #3. Explicitly, the 
rule for the interleaver DEMUX is that the octets #(3p+n), where 0<p<17 and l<n<3, shall be sent to branch #n. When a 
byte is sent to branch #n, the output from the interleaver MUX shall be the byte coming from the branch #n FIFO. The 
FIFO lengths shall be 0, 72, and 144 bytes, respectively. 

At the deinterleaver side, the FIFO lengths of branches #1, #2, #3 are 144, 72, and bytes, respectively. The octets #1, 
#4,..., #52 of each received LCH PDU shall be sent to branch #1, octets #2, #5,..., #53 to branch #2 and the other to 
branch #3. Explicitly, the rule for the deinterleaver DEMUX is that the octets #(3p+n), where 0<p<17 and l<n<3, shall 
be sent to branch #n. 



branch #1 



D 

E 
M 
U 
X 



branch #2 



72 



branch #3 



144 



M 
U 
X 



Counter from to 2 



D 

E 
M 
U 
X 



branch #1 



144 



branch #2 



72 



M 

U 
X 



branch #3 



Counter fro mO to 2 



Figure 9: Interleaver and deinterleaver 
5.8.4.6 Interleaver/deinterleaver memories initialization 

When setting up a connection, the sender shall initialize the memories of the interleaver with relevant data, which once 
transmitted can be correctly decoded by the receiver. The sender shall generate one RS code word consisting of 4 
dummy 544oyte PDUs (called a dummy RS word). The payload (49.5 bytes) shall be set to zero, the PDU type to 01, 
and the sync field correctly set as specified in 5.8.4.4. The remaining 4 bytes are used as FEC redundancy. 

The payload of the dummy PDUs is set to zero, because they are generated locally in the transmitter and receiver, and 
shall have the same content. 

The 216 bytes obtained shall be then fed twice consecutively to the interleaver according to the interleaver rules, until 
both FIFOs are full. By doing so, the contents of the FIFOs of the interleaver are as follows, where byte #1 is the first 
byte of the first dummy PDU of the dummy RS word: 

• Branch#l:NoFIFO 

• Branch #2: 72 bytes: #215 #212 #209... #2 

• Branch #3: 144 bytes: #216 #213 #210... #3 #216 #213 #210... #3 
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To save radio resources, no byte from the interleaver output shall be sent over the air during the FIFO initialization 
process, since the receiver deinterleaver can initialize its memory locally by using the same dummy RS words. With the 
same dummy RS word stored locally, the deinterleaver can achieve an equivalent initialization by taking into account 
the expected interleaver output and the deinterleaver rule. This results in the following FIFO contents in the 
deinterleaver branches after the equivalent initialization: 

• Branch #1: 144 bytes: #214 #21 1 #208... #1 #214 #21 1 #208... #1 

• Branch #2: 72 bytes: #215 #212 #209... #2 

• Branch #3: No FIFO 

Consequently, when a user PDU coming from the sender CL is input to the interleaver, the first outgoing byte at the 
deinterleaver output is byte #1 of the dummy RS word, and the n-th byte at the deinterleaver output is byte #n of the 
dummy RS word. Thus, the RS decoder works correctly. 

5.8.4.7 Connection termination 

In case a connection uses the DLC FEC mode, the end-to-end delay due to the interleaver-deinterleaver process equals 8 
PDUs. Hence, if a receiver has to decode the last PDU of a connection before the connection release, the sender shall 
take 2 actions: 

1) If a multiple of 4 PDUs is not achieved, add the missing number (1, 2 or 3) of dummy PDUs to complete a 
RS word. 

2) Purge the whole memories by generating two dummy RS words before releasing the connection. 

NOTE: The payload of the dummy PDUs used for completing the RS words and for purging can be of any values. 

Doing so, it is ensured that the last useful PDU is always read out of the deinterleaver, while the purging dummy RS 
words remain in the memories of the interleaver and the deinterleaver. 

5.9 Broadcast Transmission 

The downlink broadcast channels BCCH, FCCH, RFCH, RBCH and UBCH shall only be used by the acting CC. The 
BCCH is transmitted in the BCH and is identified by the occurrence of the BCH. The FCCH is transmitted in the FCH 
and is identified by the occurrence of the FCH. The RFCH is transmitted in the ACH and is identified by the occurrence 
of the ACH. The downlink RBCH is announced in the FCCH and is identified by MAC ID = and DLCC ID = in the 
case of the downlink. The downlink UBCH for a particular convergence layer is identified by the unique MAC ID that 
shall be assigned dynamically by the RLC (see TS 101 761-2 [2]) in the CC, taken from the MAC ID range 1 to 223, 
and DLCC ID = 63. 

The direct link broadcast channels RBCH and UBCH can be used by any H/2-HD to distribute control and user data, 
respectively, to all other H/2-HDs. The direct link RBCH is identified by the source MAC ID of the transmitting H/2- 
HD, destination MAC ID = 0, and DLCC ID = 0. The direct link UBCH for a particular convergence layer is identified 
by the unique destination MAC ID that shall be assigned dynamically by the RLC (see TS 101 761-2 [2]) in the CC, 
taken from the MAC ID range 1 to 223, the source MAC ID of the transmitting H/2-HD, and DLCC ID = 63. 

In both the CM and DM, the transmit power shall be adapted to the decoding quality of the farthest receiver. 
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5.10 Encryption 

H/2-HDs shall encrypt UDCH, UMCH, UBCH and DCCH messages carried by LCHs using the DES algorithm. The 
RBCH is not encrypted (see TS 101 761-1 [1]). Encryption of SCHs is not possible. The implementation and use of the 
Triple DES is optional (TS 101 761-1 [1]). In TS 101 761-1 [1] and TS 101 761-2 [2] a unicast encryption key is used 
by every WT for encrypted UL/DL communication on LCHs with the CC. In the HE most of the communication links 
are DiLs between two WTs. On these DiLs the unicast keys cannot be used. In a subnet, all DiL LCHs sent by a H/2-HD 
therefore shall use one single encryption key. This key is thus a common key; it is called DM Common Key. The only 
case, where H/2-HDs do not communicate over DiLs, is the sending/reception of RLC messages to/from the CC. The 
concerned channels are UL DCCH, DL DCCH and DL RBCH. In contrast to TS 101 761-1 [1], in the HE DL DCCH is 
also used for point-to-multipoint communication. This implies the use of the Common Key in the case of DL DCCH. 
For this reason and for the sake of simplicity, H/2-HDs shall use the same DM Common Key also for UL DCCH and DL 
DCCH. Furthermore, this solution has the advantage that no unicast encryption keys need to be transferred in case of a 
CC Responsibility Handover. 

NOTE: DL RBCH remains un-encrypted in HE. 

Since the DM Common Key shall be distributed to the WT in a secure way, it is nevertheless necessary that a unicast 
encryption key is generated by each WT during its assocication at the CC. For this purpose each H/2-HD shall 
implement the DES algorithm, whereas the implementation of the Triple DES is optional (TS 101 761-1 [1]). The 
choice of the encryption algorithm to be used for this purpose is negotiated between the CC and the WT during 
association (TS 101 761-2 [2]). 

During association the usage of the DM Common Key Distribution procedure shall be announced in the RLC-LINK- 
CAPABILITY-ACK message by setting the parameter DM-USE-COMMON-KEY to the value use-common-key. DM- 
USE-COMMON-KEY = no-common-key is not allowed for any H/2-HD. 

The CC shall generate a common key (see TS 101 761-2 [2]), define a Key Identifier for it, and call this key the 
DM Common Key. This key shall then be used for the encryption of all DiL as well as UL/DL DCCH LCHs of all H/2- 
HDs in the subnet. In case a low number of common keys is desirable, it is allowed to reuse the DM Common Key as 
DL Broadcast and DL Multicast Common Key. 

The DM Common Key Distribution shall be always carried out after the downlink and uplink unicast Encryption Startup 
procedure (see TS 101 761-2 [2]), after the authentication following the unicast encryption startup (association with 
authentication). In the DM Common Key Distribution procedure the CC shall send a message 
RLC_DM_COMMON_KEY_DISTR to the associating WT. The WT shall reply with the message 
RLC_DM_COMMON_KEY_DISTR_ACK. Authentication is mandatory for all installed H/2-HDs, that have 
successfully completed the PIN and time-window protected authentication key exchange process in subclause 6.9. 

The message RLC_DM_COMMON_KEY_DISTR defines the encryption algorithm that is used and contains the 
Common Key Identifier and the DM Common Key. Since the message is encrypted with the downlink/uplink unicast 
key, the DM Common Key cannot be read by an eavesdropper. 

The response message RLC_DM_COMMON_KEY_DISTR_ACK contains the descriptor of the encryption algorithm 
as a confirmation and a hash sum of the Common Key Identifier and the DM Common Key. The hash sum consists of 
the MD5 sum on the concatenation of the Common Key Identifier and the DM Common Key. 

The unicast encryption key shall be used to encrypt all sent messages during the association procedure, but in the HE it 
shall be never used after the association procedure has ended. Once associated, a H/2-HD shall always use the Common 
Key for the encryption of (DiL and UL/DL DCCH) LCHs. 

Once the DM Common Key is received by a H/2-HD, it shall use the encryption and decryption procedure in subclause 
6.7.4 of TS 101 761-1 [1] to encrypt and decrypt LCHs to and from other H/2-HDs. The seed sent periodically by the 
CC in downlink RBCH is used to support the generation of the Initialization Vector (IV) in each WT. All H/2-HDs have 
a seed generator, which cycles stepwise in the same way to produce non-repeating seeds (before it wraps) for each MAC 
frame. The seed generator of a WT shall be reset by the newly received seed from the CC, if its decoding was successful 
(TS 101 761-1 [1]). A new IV is used for each DiL LCH. The IV is a function of the locally generated seed and the 12 
LSBs of the start pointer value in the FCCH IE for that particular connection. This ensures the synchronization of the 
encryption and decryption processes for each connection, although only a single DM Common Key is used for all 
encrypted LCHs and all H/2-HDs. 
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The DL Broadcast and DL Multicast Common Keys described in TS 101 761-2 [2] shall be distributed after the 
association. The distribution of these keys is protected against eavesdropping by encryption with the DM Common Key 
in case of a H/2-HD and by encryption with the unicast key in case of a Non HE-compliant Device. Only in case that 
one or multiple Non HE-compliant Devices participate in the network, there may also be DL Broadcast or DL Multicast 
groups in which a H/2-HD wants to participate, too. While the distribution mechanism of the DM Common Key differs 
from the distribution of DL Multicast and DL Broadcast Common Keys, the refresh mechanism is the same for all 
common keys. 

As Non HE-compliant Devices shall be also supported by the CC of a HE subnet, the CC has the task to differentiate 
between H/2-HDs and Non HE-compliant Devices. The CC shall be aware that a Non HE-compliant Device will encrypt 
UL DCCH and UL UDCH with its unicast encryption key. The CC shall encrypt all messages directed to a Non HE- 
compliant Device and carried on a DL DCCH or DL UDCH with the unicast encryption key of that WT. DL UBCH and 
DL UMCH messages are encrypted with the DL Broadcast and DL Multicast Common Key, respectively. On the other 
hand, the CC shall be aware that a H/2-HD will encrypt all UL DCCH, DiL DCCH and DiL UDCH messages with the 
DM Common Key. Table 6 gives an overview over the use of the different encryption keys for the two different device 
types. A dash in a field indicates that the channel used by one device type is not used by the other device type. 



Table 6: Encryption of logical channels for H/2-HDs and Non HE-compliant Devices 



Sender 


H/2-HD 


Key used by H/2-HD 


Non HE-compliant 
Device 


Key used by Non HE- 
compliant Device 


CC 


DL DCCH 


DM Common Key 


DL DCCH 


Unicast Key of WT 


CC 






DL UDCH 


Unicast Key of WT 


CC 


DL RBCH 


Not encrypted 


DL RBCH 


Not encrypted 


CC 






DL UBCH 


DL Broadcast CK 


CC 






DL UMCH 


DL Multicast CK 


WT 


UL DCCH 


DM Common Key 


UL DCCH 


Unicast Key of WT 


WT 






UL UDCH 


Unicast Key of WT 


H/2-HD 


DiL RBCH 


DM Common Key 






H/2-HD 


DiL UBCH 


DM Common Key 






H/2-HD 


DiL UMCH 


DM Common Key 






H/2-HD 


DiL DCCH 


DM Common Key 






H/2-HD 


DiL UDCH 


DM Common Key 







NOTE 1 : H/2-HD includes both WT and CC. 

NOTE 2: If a H/2-HD is to communicate with a Non HE-compliant Device, this H/2-HD shall operate in CM with 
respect to the connections to and from the Non HE-compliant Device. 



6 Services supported by the Radio Link Control 
sublayer 

6.1 General 

The radio link control sublayer supports: 

• Association Control Function (ACF) including Encryption, Authentication and Key Management. Additionally to 
these basic functions the Home Environment shall support Multiple Convergence Layers not only for the CC but 
also for each WT. 

• Radio Resource Control (RRC): the "Dynamic Frequency Selection", the "MT Absence" and the "Power Saving 
functions" of the RRC are also required for Home Environment whereas the cellular "Handover" is an optional 
functionality for H/2 home devices. Additional functions in the home environment are the Dynamic CC Selection 
and the CC Responsibility Handover described in subclauses 6.7 and 6.8. The Power Control and the Link 
Adaptation functions for the CM are described in TS 101 761-1 [1]. The corresponding functions for the DM are 
specified in the present document. 
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• DLC User Connection Control (DUCC): the DUCC contains functions for the establishment and the modification 
both of unicast and multicast connections. The DUCC basic functions in TS 101 761-2 [2] include DUCC for the 
direct link unicast and DiL multicast without QoS negotiation. The DiL multicast with QoS negotiation is 
specified in subclause 6.6.2 of the present document. 

6.1 .1 Basic RLC Functions applied 

The following concepts of the RLC basic functions TS 101 761-2 [2] have been adopted: 

- Usage of DLC logical and transport channels for RLC messages; 

- Transfer Syntax of RLC (except DiL and DL multicast DCCH); 

- Sequencing of RLC messages; 

- ASN. 1 definition of the RLC PDUs; 

- Timers and repetitions of RLC messages. 

6.1 .1 .1 DLC User Connection Control 

The DUCC contains functions for the establishment, modification and release of unicast, multicast and broadcast 
connections. Furthermore the DUCC for direct link unicast is described in TS 101 761-2 [2]. 

6.1 .1 .2 Radio Resource Control 

Dynamic Frequency Selection 

The Dynamic Frequency Selection (DFS) is applied in the HE in the way it is supported by the TS 101 761-2 [2]. The 
DFS shall avoid the interference of other devices using the same frequency band that may arise from neighbouring H/2 
networks using the same frequency or Non HE-compliant Devices on the frequency band. The H/2 DFS scheme is 
centralized to CCs. Every CC collects measurement results and chooses the operating frequency independently of other 
CCs. 

MT Absence 

The MT Absence function is for WT maintenance purposes (scanning channels, etc.). The MT Absence in CM is 
defined in [2]. The MT Absence in DM does not differ from the procedure in CM. In DM, the user packets to be 
transmitted to a WT in the absence state are queued in the transmitting WT, not in the CC. 

6.1.2 Changed RLC Functions 
6.1.2.1 Association Control Function 

In HE, the CC is determined as a result of the CC Selection process. Its role is handed over to another CC-capable H/2- 
HD after a successful CC responsibility handover. A HE-compliant H/2-HD shall only try to associate with the CC 
whose NET-ID matches that stored in the H/2-HD, see subclause 6.9. If more than one such CC is detectable, the H/2- 
HD shall first try to associate with the CC with the best receive quality. Since the NET-ID is just a random number, it is 
possible that the same NET-ID value is used by a nearby non HE-compliant CC. Therefore, the HE-compliant H/2-HD 
shall abort the association process with a CC, as soon as it detects that this CC is not HE-compliant. Re-association with 
this Non HE-compliant CC is optional, if the HE-compliant H/2-HD cannot find any other HE-compliant CC with the 
same NET-ID, and if it is unable or not willing to become the CC of the HE-compliant network. 

NOTE 1: A manufacturer can implement on an H/2-HD different usage profiles. By selecting a Non HE-compliant 
usage profile, the user can configure a H/2-HD as a Non HE-compliant device to be preferably associated 
with a non HE-compliant CC. 

NOTE 2: A H/2-HD acting as CC may allow a Non HE-compliant Device to associate with the network. In this 

case, all H/2-HDs having communications with that Non HE-compliant Device shall operate in CM with 
respect to all connections to and from that Non HE-compliant Device. 
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Terminal Association for Multiple CLs 

After the RBCH Association message transfer the list of CL-IDs is processed by the WT. The WT shall abort the 
association process if there are no corresponding CLs supported. If several CLs are supported both by the CC and the 
WT, the WT shall select CL IDs according to a set of rules that are defined in subclause 6.2. The WT transmits the 
selected CL-ID-list to the CC in the RLC_LINK_CAP ABILITY message which is sent after the MAC ID assignment. 

6.1 .2.2 Radio Resource Control 

Handover 

The "Radio Handover", "Network Handover" and "Forced Handover" as described in the TS 101 761-2 [2] are only 
optional for H/2-HDs, since no cellular infrastructure can be assumed for private homes. 

Power Saving 

The Power Saving functions are initiated by the WT with the purpose of entering or leaving low consumption modes and 
controlling the power of the transmitter. Direct link connections addressed to a WT that is in a power saving state shall 
not be scheduled by the CC. The CC shall wake up the sleeping WT, when detecting another WT having pending data 
for this sleeping WT. 

6.1 .3 Changed RLC Messages, Parameter Settings 

6.1.3.1 Association Control Function 

In the home environment no Network Operator ID shall be applied. Therefore the NOP-ID field shall not be used in the 
RBCH Association message. 

The parameters exchanged during association and being relevant to H/2-HDs are described below: 

direct-mode-cap: The value of the direct-mode-cap field shall be set to 1 ("dm-capabilities") for all H/2- 

HDs. (message: RLC_LINK_CAP ABILITY). 

cl-vid-list: H/2-HD may support more than one CLs. The IDs of these CLs shall be included in this 

CL-ID-List (messages: RLC_RBCH_ASSOCIATION, RLC_LINK_C APABILIT Y) . 

support-fsa: H/2-HDs supporting isochronous services shall support FSA, and set Support-FSA field to 

the value 1 ("support-fsa") (message: RLC_LINK_CAPABILITY, 
RLC_LINK_C APABILIT Y_ACK) . 

cc-ho-cap: A CC -capable H/2-HD supporting CC responsibility handover shall set this paramter field 

to cc-ho-supported. (message: RLC_LINK_CAP ABILITY). 

dm-use-common-key: This parameter field is used to indicate if the DM Common Key distribution procedure is 

performed. It shall be set to the value "use-common-key", (message: 
RLC_LINK_C APABILIT Y) . 

dm-attributes: The parameter field dil-power-control shall be set to dil-dynamic-pc, the parameter fields 

rx-arq-win-size and tx-arq-win-size shall be set to the supported ARQ window size, 
(message: RLC_LINK_CAPABILITY, RLC_LINK_CAPABILITY_ACK). 

6.1 .3.2 DLC User Connection Control 

The following parameters contained in the setup/modify messages for DiL UDCH and DiL UMCH shall be set as 
follows: 

cl-id: This parameter shall be set to the ID of the CL instance that sets up or modifies a DiL 

UDCH or DiL UMCH. 

NOTE: CL-ID is also used by the join and leave procedures for DiL UBCH or DiL UMCH. 
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allocation-type: The allocation-type parameter in duc-descr describes the type of connection: basic, fca, or 

fsa. fee-used: The fee-used flag shall be set for each DiL UDCH or DiL UMCH that 
uses FEC mode. 

fee: The fee field defines the coder type and the interleaver type of the applied FEC. 

6.1 .4 New RLC Functionality 

CC Selection, CC Responsibility Handover 

Because of the ad hoc network topology, additional functions like the CC selection procedure and the CC Responsibilty 
Handover procedure are introduced in subclauses 6.7 and 6.8. Support for CC Selection is mandatory for CC -capable 
H/2-HDs. 

Direct Link related Functions 

Support for DiL Link Adaptation, DiL Power Control, and Link Quality Calibration, are mandatory for H/2-HDs. The 
corresponding functions are specified in subclauses 6.3, 6.4, and 6.5. 

The DiL UMCH setup/modify/release is specified in subclause 6.6.2, and the use of DiL UBCH is specified in subclause 
5.9. The support for DiL UMCH and DiL UBCH is mandatory for H/2-HDs. 

Authentication Key Exchange 

The Key Exchange with special reference to direct link requirements is specified in subclause 6.9. 

6.2 Terminal association for multiple convergence layers 

In the HE multiple active CLs may make use of multiple CLs, since WTs may be connected to different types of fixed 
networks, for example IEEE 1394 and Ethernet. In this case, the terminal association is done in several steps. In the 
RBCH Association procedure the CC shall inform the WT about the CLs supported in parallel by the CC, using the cl- 
vid-list parameter. During the link capability procedure, the WT informs the CC about the CLs it wants to associate 
with, also using a cl-vid-list. The WT's cl-vid-list shall be a sub-set of the cl-vid-list sent by the CC. If none of the CL 
IDs sent in RBCH association message is supported by the WT, the WT shall not continue with the association. 

In case of successful negotiation of CL-IDs, the info transfer procedure (see TS 101 761-2 [2]) shall be subsequently 
performed between the WT and the CC for each selected CL-ID. Per CL-ID one info transfer is performed. The format 
of the INFO_PDU is described in TS 101 761-2 [2]. After successful association of the CLs, the CL-specific C-SAP(s) 
and U-SAP(s) are created for the individual CL-IDs. During DiL UDCH or DiL UMCH setup the CL-ID contained in 
the messages identifies the C-S AP of the addressed CL. After the setup of a DIL UDCH or DiL UMCH, the DUC-ID 
implicitly identifies the U-SAP of the addressed CL. 

6.3 Link Adaptation in Direct Link Phase 

In unicast DiL communication only the receiver is allowed to recommend a new PHY mode based upon the packet 
decoding quality at any time. In this case the receiver shall set the PHY mode LCH and PHY mode SCH parameters in 
RR for DiL to the proposed new PHY mode, see subclause 6.2.9.1 of TS 101 761-1 [1]. The parameters #SCH and 
#LCH shall be set to zero. 

NOTE: In contrast to a RR for DiL used for unicast link adaptation (#LCH=#SCH=0), which is issued by a 
receiver, the RR for DiL with #LCH>0 and/or #SCH >0 can only be sent by the transmitter of a DiL 
connection to request LCH(s) and/or SCH(s). 
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In multicast/broadcast DiL communication, link adaptation shall only be performed in conjunction with dynamic power 
control in subclause 6.4.2. Here, a new PHY mode shall only be recommended by the sender of a multicast connection, 
which is defined uniquely by the sender MAC-ID and the multicast MAC -ID. The sender of a multicast connection may 
propose a more robust PHY mode, if the transmit power for this connection has reached the upper boundary, and at least 
one of its receivers is suggesting a higher transmit power. It can propose a less robust PHY mode, if the transmit power 
for this connection has reached the lower boundary, and all of its receivers are suggesting a lower transmit power. The 
sender of the multicast connection shall use a RR for DiL to recommend the new PHY mode for LCH and/or SCH. It 
shall set #LCH and/or #SCH to zero, if no real resources are requested by this RR. 

For both direct link unicast and multicast, the CC shall not change the PHY mode of a DiL connection without 
recommendation from the involved WTs. 

6.4 Power Control in Direct Link Phase 

Dynamic power control, in direct link phase, enables the transmitting WT to always set its transmit power level 
appropriately, to provide acceptable reception quality at the receiving WT. This is determined according to the explicit 
recommendation from the receiver to the transmitter, to increase or decrease its power level by a certain value (dB). The 
criteria the receiver uses to determine this value is implementation specific. 

NOTE: The receiving WT might use received signal strength (RSS) or the BER of received data as a criteria for 
reception quality. 

Dynamic power control shall be supported by all H/2 home devices. Dynamic power control for unicast and 
multicast/broadcast connections in direct link is described below. 

For the purpose of power control in unicast and multicast/broadcast, the message RLC_DM_POWER_CONTROL is 
used as described below: Since unicast and multicast/broadcast PDUs from the same sender are not necessarily received 
in one PDU train, dynamic power control is performed separatedly. A connection type field dm-duc-type in 
RLC_DM_POWER_CONTROL indicates whether the recommendation concerns unicast or multicast/broadcast PDUs 
originating from the same sender. 

RLC_DM_POWER_CONTROL messages shall be always transmitted using the most robust PHY mode. The transmit 
power level may vary, and is specified below. 

6.4.1 Direct Link unicast power control 

Dynamic power control shall be performed for each unicast DUC in DiL, for both simplex and duplex connections. Two 
WTs that have several DUCs, using different PHY modes, would usually require different transmit power levels. 
However, since PDUs belonging to different DUCs which are sent from one WT to a peer WT in one MAC frame, are 
transmitted in a train, the same transmit power level shall be used for all PDUs in the train. The transmit power level is 
set to satisfy the connection with the worst reception quality (i.e. less robust PHY mode). This is provided by the 
receiver's explicit recommendation. 

In unicast, the power control scheme in direct link phase is performed as follows: 

1) Connectivity Check: performed during the first DiL DUC Setup between a WT pair; 

2) Power Update: performed after each DiL DUC Setup involving the same WT pair, and during the lifetime of 
their unicast connections. 

During the first DiL DUC Setup, the peer WTs exchange power control messages, in order to check if a direct radio link 
is possible. After the first connection setup is successfully completed, and during the life time of the connection, power 
update is dynamically performed, to inform the sender about appropriate transmit power level. Power update can also be 
performed after a further DiL DUC setup between the same WT pair, to take into account different power requirements 
for different PHY modes. 
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6.4.1.1 



Connectivity Check 



Connectivity check is performed only for the first DiL DUC between two WTs using RLC_DM_POWER_CONTROL 
messages. During the setup of the first unicast DiL DUC (see TS 101 761-2 [2]), the CC enables both WTs to perform 
connectivity check by granting each WT at least one DiL DCCH to transmit its power control message, using a SCH. 
The CC itself can be one of the WTs. The CC shall send the RGs to both WTs, after the second 

RLC_DM_CONNECT_ACK message (to WT2), and before the first RLC_DM_CONNECT_COMPLETE message (to 
WT1), have been sent. This is shown in the following MSCs for both CC and WT initiated DUC setup. The CC may 
grant resources for connectivity check several times during this period. All these granted DiL DCCH SCHs to this WT 
pair shall be used for connectivity checking. All RLC_DM_POWER_CONTROL messages sent for connectivity check 
shall be transmitted at maximum allowed power level. 




- CC grants DCCH SCHs for WT1 and WT2, implicit power control trigger 

- WT1 transmits RLC power control message, WT2 measures reception quality 

- WT2 transmits RLC power control message, WT1 measures reception quality 






RLC_DM_CONNECT_COMPLETE-ACK 


If connectivity check was ^ 
successful! 


RLC_DM_CONNECT_COMPLETE 




RLC_DM_CONNECT_COMPLETE-ACK 

If connectivity check was 
successful! 


Disestablished 



Figure 10: Direct Link Setup procedure - CC initiated 
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CC grants DCCH SCHs for WT1 and WT2, implicit power control trigger 
WT1 transmits RLC power control message, WT2 measures reception quality 
WT2 transmits RLC power control message, WT1 measures reception quality 



RLC DM CONNECT COMPLETE 



RLC_DM_CONNECT_COMPLETE_ACK 

If connectivity check was 
successful! 



RLC_DM_CONNECT_COMPLETE 



RLC_DM_CONNECT_COMPLETE_ACK 



If connectivity check was 
successful! 



DUC established 



Figure 11 : Direct Link Setup procedure - WT initiated 



RLC-DM-POWER 


CONTROL-ARG::= SEQUENCE { 


rlc-pdu-type 


RLC-HE-SCH-PDU-TYPE, 


extension-type 


EXTENSION-TYPE, 


dm-duc-type 


DM-DUC-TYPE, 


wt-tx-level 


TX-LEVEL 


adjust-tx 


ADJUST-TX } 



The RGs are considered as an implicit trigger for connectivity check. No RR shall be generated by the WTs. On 
reception of such an RG, each WT transmits RLC_DM_POWER_CONTROL message to the peer WT, using the 
maximum allowed transmit power level for the frequency band of operation. Each WT measures then the reception 
quality (e.g. using RSS, BER, etc. . .) of the RLC_DM_POWER_CONTROL message from the peer WT. 
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Either WT shall abort the DiL DUC connection setup in the following cases: 

• It is not granted at least one DiL DCCH SCH, or cannot successfully decode at least one corresponding RG, 
before receiving the RLC_DM_CONNECT_COMPLETE message from the CC. 

• It could not receive the RLC_DM_POWER_CONTROL message, or the reception quality was not acceptable. 

In order to reject the DiL DUC Setup the WT shall send RLC_DM_RELEASE message and continue with the DiL 
Release procedure. 

Either WT shall only acknowledge the RLC_DM_CONNECT_COMPLETE message from the CC with 
RLC_DM_CONNECT_COMPLETE_ACK, after it has successfully decoded at least one 
RLC_DM_POWER_CONTROL message from the peer WT, and it has sent at least one 
RLC_DM_POWER_CONTROL message to the peer WT. 

In case both WTs successfully acknowledged the RLC_DM_CONNECT_COMPLETE from the CC, the connectivity 
check is considered successful, and the connection setup is successfully completed. 

6.4.1.2 Power Update 

As long as there is at least one unicast connection between a WT pair, power update is performed whenever it is 
necessary. After each further unicast connection setup or release, either WT should consider performing power update, 
to ensure always satisfying the connection with worst reception quality. 

Each WT continuously monitors the received signal quality of all its unicast connections with the peer WT. If a WT 
detects a worsening or an improvement of the received signal strength or another reception quality criterion 
(implementation specific) above an acceptable threshold, it should request a DiL DCCH SCH to transmit a 
RLC_DM_POWER_CONTROL message. The message contains an explicit recommendation to the peer WT to adjust 
its transmit power level for unicast traffic appropriately. For the RLC_DM_POWER_CONTROL message transfer the 
WT shall use the most robust PHY mode. If this message is transmitted together with other PDUs, the regulated Power 
level, otherwise the maximum transmit power level, shall be used for the unicast transmission. 

Even though the radio channel can be considered symmetric in most of the cases, it is recommended that a transmitting 
WT1 only adapts its power level based on explicit recommendation from the receiving WT2. WT1 should not change its 
transmit power level based on the change of its own reception quality for WT2. 

Latest, two frames after either WT has successfully decoded the received RLC_DM_POWER_CONTROL message 
with explicit recommendation, it shall start to transmit all its direct link unicast traffic to the peer WT, using the adjusted 
power level. 

The power control scheme in direct mode should not react on burst changes of the radio channel, rather on persistent 
changes. The exact algorithm is implementation specific. 

In case the PHY mode is changed during a connection, the WTs might also readjust the transmit power levels 
accordingly. 

In addition to the dm-duc-type field and recommendation for power control, the RLC_DM_POWER_CONTROL 
message also contains the current transmit power level of the sender of this message, for all its unicast connections with 
the receiving WT. Thus, the receiving WT recognizes whether the transmitter has reached the lower or upper transmit 
power limit in the frequency band of operation. In this case, the peer WTs might initiate a change of PHY mode for link 
adaptation, see subclause 6.3. 

If a WT does not react to a recommendation from its peer WT after two frames, the originator of the recommendation 
shall retransmit its RLC_DM_POWER_CONTROL message. 

In case the receiving WT can no more successfully decode the received user data, it shall transmit its 
RLC_DM_POWER_CONTROL message at the maximum transmit power level, informing the sender to increase its 
transmit power level to the recommended value. If the receiver is still not able to successfully decode received data, it 
might trigger a PHY mode change for link adaptation, before it releases the connection. 

RLC_DM_POWER_CONTROL messages can be exchanged anytime by just requesting SCH for DiL DCCH, as long as 
there is at least one connection between the WT pair. 
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6.4.2 Direct Link Multicast/Broadcast Power Control 

In the case of multicast and broadcast connections, a quasi static transmit power control scheme shall be applied. The 
sender shall start transmission of the first multicast/broadcast connection, at 3 dB below the maximum allowed transmit 
power level for the centre frequency where it is operating. No connectivity check is performed in DiL broadcast or 
multicast connections (both with and without connection setup). 

After multicast/broadcast connection has started (corresponding RGs in FCH), each receiving WT shall send its 
RLC_DM_POWER_CONTROL message to the multicast/broadcast sender, latest within a timer 
T_mc_dm_power_control. A receiving WT that could successfully decode the corresponding user data informs the 
multicast/broadcast sender to decrease its transmit power level by a certain value. A receiving WT that could not 
successfully decode the user data requests the multicast/broadcast sender to increase its transmit power level 
appropriately. The multicast/broadcast sender shall adjust its transmit power level, in order to satisfy the receiver with 
the worst reception quality, i.e. which recommended highest increase or lowest decrease of power level. The sender shall 
always ensure that it is compliant with the maximum allowed transmitted power level for the centre frequency where it is 
operating. 

Similar to unicast, the sender shall always use the same transmit power level for all its active multicast and broadcast 
connections, even if different multicast groups are target. The receiving WTs should therefore determine the required 
transmit power adjustment for a certain multicast/broadcast sender, based on the multicast or broadcast connection with 
the worst reception quality. 

During the lifetime of all multicast/broadcast connections from the same sender, each receiving WT shall send its 
RLC_DM_POWER_CONTROL message to the sender whenever necessary, but not less than once every 
T_mc_dm_power_control. The sender should adjust its transmit power level, if it notices that all receiving devices have 
a persistently acceptable reception quality according to their RLC_DM_POWER_CONTROL messages. 
Recommendations from multicast/broadcast receivers to increase the transmit power level shall be applied latest two 
frames after reception of the corresponding RLC_DM_POWER_CONTROL message. The multicast/broadcast sender 
shall however not reduce its transmit power level by more than 3 dB within T_mc_dm_power_control. This shall ensure 
that the sender does not react to burst characteristics of the radio channel. 

Since a new multicast/broadcast connection might require higher transmit power level than already active ones (if it uses 
different PHY mode, or it targets different multicast receivers), each new multicast/broadcast connection shall be started 
at 3 dB below the maximum allowed transmit power level, or the currently used multicast/broadcast power level if it is 
higher. Consequently, latest when a new multicast/broadcast connection is started, the sender shall have increased the 
power level of all its active multicast/broadcast connections, if it was originally less then 3 dB below the maximum 
power. If the power level of active connections already exceeds this level, the same level shall be used for the new 
connection as well. After the new multicast/broadcast connection is started, the appropriate transmit power level is 
determined based on the receiver's recommendations. 

NOTE: The sender may steadily perform the increase of power level for example during multicast connection 
setup. 

RLC_DM_POWER_CONTROL messages for direct link multicast/broadcast power control may be transmitted together 
with unicast traffic to the multicast sender. In this case, this message may be transmitted at regulated transmit power 
level for unicast traffic. Otherwise, the RLC_DM_POWER_CONTROL message shall be transmitted using the 
maximum transmit power level. Thus it can be assumed that the sender can successfully decode the messages from those 
receivers, where direct link connection is possible. The sender may initiate link adaptation (6.3), if the transmit power 
for its multicast/broadcast connections has reached the upper (lower) boundary, and at least one (all) of its receivers is 
suggesting a higher (lower) transmit power. 

A multicast/broadcast receiver may retransmit its RLC_DM_POWER_CONTROL message several times to request the 
sender increase its power level, if the sender does not satisfy this request within two frames. The receiver may leave the 
multicast/broadcast group if the reception quality is still not acceptable. 

A new WT that joins a multicast/broadcast group, first checks if a connection is active (corresponding RGs in FCH). 
Depending on the reception quality of all active multicast/broadcast connections from the same sender, the new WT 
shall send its RLC_DM_POWER_CONTROL message with appropriate recommendation, latest within 
T_mc_dm_power_control. 



ETSI 



36 



ETSI TS 101 761-4 V1.1.1 (2000-06) 



6.5 Link Quality Calibration for DM operation 

The link quality calibration aims at creating a map of the network, which describes the quality of the radio link between 
each WT pair, including the CC. The link quality map is required by H/2-HDs for several reasons, for example CC 
responsibility handover, future support of hidden nodes, loop detection in 1394 networks, etc. 

6.5.1 Principles of Calibration 

The calibration procedure consists of two phases: measurement phase and reporting phase. It is always triggered by the 
CC, and it is started in two cases: 

• High Priority Calibration 

When a new WT joins the network, the CC shall trigger a calibration procedure with high priority. The CC 
allocates resources for the measurement and reporting phases as described in the following clauses. 

• Low Priority Calibration 

To keep the link quality map of the network up to date, the CC shall trigger low priority calibrations, if spare 
resources are available. It is up to the CC to determine the frequency of low priority calibrations. Depending on 
the mobility of the WTs, the update interval might vary from 100 milliseconds to a few minutes. The algorithm to 
determine the frequency of calibration is an implementation specific issue. 

NOTE: If the CC is to take a decision based on the link quality map, such as to select the best CC-candidate, it 
should be aware that an RSS2 value in the link quality map could be outdated. 

The triggers for both measurement and reporting phases have a lifetime of T_trigger_lifetime each. Within the lifetime 
of a measurement or report trigger the CC shall send out neither a new measurement trigger, nor a new report trigger. 
The lifetime of a measurement or report trigger begins with the start of the next MAC frame following the MAC-frame 
that contains that trigger PDU. 

Since link quality calibration is always triggered by the CC, only Resource Grant messages are required (no RR for 
calibration). Resource grants for measurement and report PDUs are announced in FCCH, using the RG IE for DiL 
RBCH. The CC shall act as a WT to use the measurement PDUs during the measurement phase. 

All measurement, report and trigger messages shall be transmitted using the most robust PHY mode, and the maximum 
transmit power level. Further, it is suggested that the entire link quality calibration is always performed using omni- 
directional antennas, at both transmitter and receiver sides, without support of antenna diversity. This enables a fast 
calibration of the network. A more accurate calibration of the network, using sectorized antennas, requires very 
extensive measurements. 

NOTE: The omni-directional antenna can be implemented using existing sectorized antennas. 

The CC may wake up a sleeping WT (TS 101 761-2 [2]) to perform measurement or report. 

The granted calibration measurement and report DiL RBCH resources may become ambiguous for a WT, if it had not 
received the corresponding trigger within the last T_trigger_lifetime and it had not sent a RR for the same DiL RBCH 
resources before the grant. If a WT cannot unambiguously identify the purpose of a granted DiL RBCH SCH or DiL 
RBCH LCH, it shall send a dummy DiL RBCH SCH or LCH PDU with all payload bits set to zero. 

NOTE: A WT may use granted DiL RBCH resources for purposes other than calibration, if it had not received the 
corresponding calibration trigger within the last T_trigger_lifetime and it had sent a RR for the same DiL 
RBCH resources before the grant. 

The CC maintains the resulting link quality map of the network, and may be requested by any WT to broadcast its 
contents as described in subclause 6.5.4. 
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6.5.2 Measurement Phase 

The measurement phase is started by the calibration-measurement trigger broadcast by the CC. The lifetime of the 
measurement trigger is T_trigger_lifetime, within which a triggered WT1 is granted a SCH for DiL RBCH to be sent as 
measurement PDU. This PDU shall be received by other WTs to determine the quality of their links to WT1. The 
measurement phase for WT1 is completed after the trigger has expired. 



6.5.2.1 



Calibration-Measurement Trigger 



The CC shall trigger the start of the measurement phase by broadcasting the 

RLC_CALIBRATION_MEASUREMENT_TRIGGER message using a downlink RBCH SCH. Selective triggering 
shall be enabled for simultaneous calibration measurements and calibration reporting from different WTs (Figure 12). 
The trigger type indicates whether all WTs will be requested to perform calibration measurement, or only a set of 
selected WTs. In case only a set of WTs (up to three) is triggered, the corresponding MAC -ID list shall be included in 
the trigger message. 



MSC Calibration_Measurement_T rigger 



WT ENV 



WT RLC 



CC RLC 



RLC CALIBRATION MEASUREMENT TRIGGER 



RRC_calibration_measu re men t_Tri ggerj nd 



' mac-id (broadcast), 
trigger-type, 
mac-id-list) 



RRC_calibration_Measurement_Trigger_Req 



(trigger-type, 
mac-ids) 



CC ENV 



(mac-id (broadcast), 
trigger-type, 
mac-ids) 



DL RBCH 



Figure 12: MSC for RLC_CALIBRATION_MEASUREMENT_TRIGGER 

The RLC_CALIBRATION_MEASUREMENT_TRIGGER message shall be transmitted using the most robust PHY 
mode. 

After calibration measurement trigger, the CC shall grant DiL RBCH resources to all, or a set of WTs to transmit 
calibration measurement PDUs in direct link. Only DiL RBCH SCHs granted within the lifetime of the measurement 
trigger shall be regarded as measurement PDUs. 



Table 7: RLC-CALIBRATION-MEASUREMENT-TRIGGER 



RLC-CALIBRATION-MEASUREMENT-TRIGGER -ARG::= SEQUENCE { 



rlc-pdu-type 
extension-type 
trigger-type 
mac-ids 



RLC-HE-SCH-PDU-TYPE, 
EXTENSION-TYPE, 
TRIGGER-TYPE, 
MAC-IDS } 
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6.5.2.2 



Calibration Measurement 



After reception of a (network-wide or selective) calibration-measurement trigger message from the CC, a WT that is 
granted a SCH in DiL RBCH as transmitter, shall broadcast a RLC_CALIBRATION_MEASUREMENT message 
during direct link phase (Figure 13). It shall set the source MAC -ID of this DiL RBCH to its own MAC -ID. 

A WT, which is granted a DiL RBCH SCH without having received a measurement trigger message from the CC during 
the last T_trigger_lifetime (the measurement trigger lifetime) shall not use this DiL RBCH SCH for calibration 
measurement. It may use this DiL RBCH SCH for purposes other than calibration, if it has sent a RR for DiL RBCH 
SCH before. 



MSC Calibration Measurement 



WT ENV 



WT RLC 



CC RLC 



CC ENV 



RRC_calibration_measurement_req 



(mac-id, peer-mac-id (broadcast)) 



RLC CALIBRATION MEASUREMENT 



DiL RBCH 



RRC calibration measurement ind 



(mac-id, peer-mac-id (broadcast)) 



Figure 13: MSC for RLC_CALIBRATION_MEASUREMENT 

The RLC_CALIBRATION_MEASUREMENT message shall be transmitted using the most robust PHY mode and 
maximum allowed transmit power level in the frequency band of operation. 

The RLC_CALIBRATION_MEASUREMENT message will be received by all other WTs (including the CC), which 
can listen to the sender of this message. Upon reception of this message, each WT (including the CC) shall perform 
physical layer measurement of received signal strength (referred to as RSS2 for Direct Link (TS 101 475 [3])), and shall 
compare it to the previously measured value, if available. In case that the RSS2 value difference exceeds a threshold of 
±6 dB, the corresponding value in the local link quality map shall be updated. This value is reported during the report 
phase as described below. 



6.5.3 Reporting Phase 



The reporting phase is started by the calibration-report trigger, broadcast by the CC. The lifetime of the report trigger is 
T_trigger_lifetime, within which a triggered WT1 is granted a SCH for DiL RBCH to be sent as report PDU. This PDU 
shall be received by the CC to update the global link quality map. It shall also be received by other WTs to update their 
locally stored (partial) link quality maps, if any. The reporting phase for WT1 is completed after the trigger has expired. 
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6.5.3.1 



Calibration-Report Trigger: 



The CC shall trigger the start of the reporting phase by broadcasting the RLC_CALIBRATION_REPORT_TRIGGER 
message using a downlink RBCH SCH (Figure 14). The report trigger shall indicate whether all WTs, or a set of 
selected WTs shall report their calibration measurement results. In case that a set of WTs (up to three) is triggered, the 
corresponding MAC-ID list shall be included in the trigger message. 



MSC Calibration_Report_T rigger 



WT ENV 



WT RLC 



RLC CALIBRATION REPORT TRIGGER 



F i RC_ca I i br at io n_re po rt_t rig ge r_i nd 



( mac-id (broadcast), 
trigger-type, 
mac-ids) 



CC RLC 



FlRC_calibration_report_trigger_req 



(trigger-type, 
mac-ids) 



CC ENV 



(mac-id (broadcast), 
trigger-type, 
mac-ids) 



DL RBCH 



Figure 14: MSC for RLC_CALIBRATION_REPORT_TRIGGER 

The RLC_CALIBRATION_REPROT_TRIGGER message shall be transmitted using the most robust PHY mode. 

After calibration report trigger, the CC shall grant DiL RBCH resources to all, or a set of WTs to transmit calibration 
report PDUs in direct link. Only DiL RBCH SCHs granted within the lifetime of the report trigger of T_trigger_lifetime 
shall be regarded as calibration report PDUs. 

Table 8: RLC-CALIBRATION-REPORT-TRIGGER 



RLC-CALIBRATION-REPORT-TRIGGER -ARG::= SEQUENCE { 



rlc-pdu-type 
extension-type 
trigger-type 
mac-ids 



RLC-HE-SCH-PDU-TYPE, 
EXTENSION-TYPE, 
TRIGGER-TYPE, 
MAC-IDS } 



6.5.3.2 



Calibration Report: 



Depending on the number of calibration measurements performed, the CC may grant SCHs or LCHs to a triggered WT 
to send its reports. After reception of a (network-wide or selective) calibration-report trigger message from the CC, a 
WT that is granted a SCH or LCH in DiL RBCH as transmitter, shall broadcast a 

RLC_SHORT_CALIBRATION_REPORT or RLC_CALIBRATION_REPORT message during direct link phase 
(Figure 15). It shall set the source MAC-ID of this DiL RBCH to its own MAC-ID. In the case of SCH, 
RLC_SHORT_CALIBRATION_REPORT contains up to two reports. In the case of LCH, 

RLC_CALIBRATION_REPORT may contain up to 22 reports. The field number-of-reports describes the number of 
actual reports contained in the current LCH PDU. 
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A WT, which is granted a DiL RBCH SCH or LCH without having received a report trigger message from the CC 
during the last T_trigger_lifetime (the report trigger lifetime) shall not use this DiL RBCH SCH or LCH for calibration 
reporting. It may use this DiL RBCH SCH or LCH for purposes other than calibration, if it has sent a RR for DiL RBCH 
SCH, or LCH, respectively, before. 



MSC Calibration_Report_v1r0 



WT ENV 



WT RLC 



CC RLC 



CC ENV 



RRC_calibration_report_req 



(mac-id, peer-mac-id (broadcast), 
rep-buff-status, report-list ) 



alt 



RLC SHORT CALIBRATION 



({rep-buf-status, 
mac-id-1, rss2-of-wt-1, 
mac-id-2, rss2-of-wt-2}) 



RLC CALIBRATION REPORT 



({rep-buf-status, cal-report-list} ) 



REPORT 



DiL RBCH on SCH 



DiL RBCH on LCH 



R RC_calibra1ion_report_ind 



(mac-id, peer-mac-id (broadcast), 
rep-buff-status, report-list ) 



Figure 15: MSC for RLC_CALIBRATION_REPORT 

The RLC_SHORT_CALIBRATION_REPROT and RLC_C ALIB RATION_REPROT messages shall be transmitted 
using the most robust PHY mode, and the maximum allowed transmit power level in the frequency band of operation. 

Table 9: RLC-SHORT-CALIBRATION-REPORT 



RLC-SHORT-CALIBRATION-REPORT-ARG::= SEQUENCE { 


rlc-pdu-type 


RLC-HE-SCH-PDU-TYPE, 


extension-type 


EXTENSION-TYPE, 


rep-buf-status 


REP-BUF-STATUS, 


mac-id-1 


MAC-ID, 


rss2-of-wt1 


RSS2-VALUE, 


mac-id-2 


MAC-ID, 


rss2-of-wt2 


RSS2-VALUE} 


Table 10: RLC-CALIBRATION-REPORT 


RLC-CALIBRATION-REPORT-ARG::= SEQUENCE { 


rlc-pdu-type 


RLC-HE-LCH-PDU-TYPE, 


extension-type 


EXTENSION-TYPE, 


rep-buf-status 


REP-BUF-STATUS, 


cal-report-list 


CAL-REPORT-LIST } 
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Each WT shall arrange the measured RSS2 values according to their relative change since the last calibration 
measurement. Those RSS2 values with the highest change shall be reported first. Depending on the granted resources, 
the WT transmits all or part of its reports. In case the WT could not report all RSS2 measurement values that have 
changed by more than ±6 dB, it may indicate in the report PDU by setting the rep-buf-status bit that more resources are 
required. 

From time to time, the CC may want to receive all RSS2 values from a WT. In this case the CC shall grant sufficient 
SCHs or LCHs for DiL RBCH to this WT, so that even those RSS2 values whose changes are below ±6 dB, can be 
included in the calibration report PDU. 

The report list includes the MAC-ID of the measured WT and the corresponding RSS2 value. 

NOTE: The received signal strength of the reports can also be used to check the local topology map. 

6.5.4 Link Quality Map of the Network 

Once all WTs have reported their measurement results, the CC creates and stores the link quality map of the network, 
which indicates the quality of connectivity between each WT pairs. The link quality map of a network with n associated 
WTs (including the CC), can be represented by a matrix: 



Table 11 : Link quality map of the network 





MAC-ID1 


MAC-ID2 
RSS2 1 2 


MAC-IDi 
RSS2 1 i 




MAC-IDn 
RSS2 1 n 


MAC-ID1 




MAC-ID2 


RSS2 2 <- 1 




RSS2 2 i 




RSS2 2 ^ n 


MAC-IDx 


RSS2 x <- 1 


RSS2 x <- 2 






RSS2 x <- n 














MAC-IDn 


RSS2 n 1 


RSS2 n^2 


RSS2 n i 







RSS2 n<-m represents the DiL received signal strength measured at WT n, when transmitted by WT m. 

• A row corresponds to how a given WT receives all other WTs. RSS2 information contained in a row is gathered 
as it is measured by the WT. 

• A column corresponds to how a WT is received by all other WTs. RSS2 information contained in a column is 
gathered as it is broadcast to other WTs. 

Each WT stores locally the relevant part of the map, i.e. the corresponding row and column. The CC shall store the 
complete link quality map of the network. The CC may assign a timer to each RSS2 value in the link quality map so as 
to handle partial reporting or some reports received in error. Timers are initialized by the CC when measurements are 
performed. 

The CC may distribute the link quality map of the network to a single or to all WTs in the network. A specific RLC 
PDU is defined for this purpose, called RLC_CALIBRATION_LINKQUALITYMAP. The 
RLC_CALIBRATION_LINKQUALITYMAP may be send upon request of a WT 
(RLC_CALIBRATION_LINKQUALITYMAP_REQUEST) or without an explicit request from a WT. 

NOTE: In the latter case the point in time or the period of the link quality map broadcast is out of the scope of the 
present document. 

Figure 16 gives an overview of the distribution of the link quality map. Without an explicit request from a WT only the 
lower part of the figure is carried out. 
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MSC Calibration_LinkQualityMap 



WT ENV 



WT RLC 



CC RLC 



CC ENV 



RRC_calibra1ion_ 

L I N KQ U A LI TY M AP_ Req ue st_r eq 



(mac-id, request-type, mac-id) 



RRC_calibration_ 
LINKQUALITYMAP_Request_cnf 



( mac-id(broadcast), 
map-ext-ind, 
complete- report- list) 



RLC_CALIBRATION_ 
LINKQUALITYMAP_REQUEST 



(request-type, mac-id) 



RLC_CALIBRATION_ 
LINKQUALITYMAP_ 
REQUEST ACK 



( map-ext-ind, 
complete- report-list) 



DiLRBCH 



RRC_calibration_ 
LINKQUALITYMAP_Request_ind 



(mac-id, request-type, mac-id) 

RRC_calibration_ 
LINKQUALITYMAP_Request_rsp 



(mac-id(broadcast), 
map-ext-ind, 
complete- report-list) 



Figure 16: MSC for RLC_CALIBRATION_LINKQUALITYMAP_REQUEST and 
RLC_CALIBRATION_LINKQUALITYMAP 

The RLC_CALIBRATION_LINKQUALITYMAP_REQUEST and RLC_CALIBRATION_LINKQUALITYMAP 
messages shall be transmitted using the most robust PHY mode. 



Table 12: RLC-CALIBRATION-LINKQUALITYMAP-REQUEST 



RLC-CALIBRATION-LINKQUALITYMAP-REQUEST-ARG::= SEQUENCE { 



rlc-pdu-type RLC-HE-SCH-PDU-TYPE, 

extension-type EXTENSION-TYPE, 

mac-id MAC-ID, 

request-type REQUEST-TYPE } 



Table 13: RLC-CALIBRATION-LINKQUALITYMAP 



RLC-CALIBRATION-LINKQUALITYMAP -ARG::= SEQUENCE { 



rlc-pdu-type 
extension-type 
map-ext-ind 
complete-report-list 



RLC-HE-LCH-PDU-TYPE, 
EXTENSION-TYPE, 
MAP-EXT-IND, 
COMPLETE-REPORT-LIST } 



Within the RLC_CALIBRATION_LINKQUALITYMAP_REQUEST a parameter called request-type indicates whether 
the whole map is requested or only a partial map. A partial map corresponds to a column in Table 11, which includes the 
RSS2 values with which all other WTs have received the RLC_CALIBRATION_MEASUREMENT PDU from the WT 
with mac- id. 
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To unify complete and partial quality map encoding, the link quality map shall be encoded by columns. This means that 
each (partial) report consists of the MAC-ID of the WT that has sent RLC_CALIBRATION_MEASUREMENT, and N 
times the MAC -ID, RSS2 value and the age of the measurement for each of the N receiving WTs. A complete report list 
is composed of several partial reports (for all sending WTs). An age of measurement field has been included to indicate 
when the RSS2 value has been updated for each of the receiving WTs. The field map-ext-ind (map-end, map-continue) 
indicates whether more RLC_CALIBRATION_LINKQUALITYMAP PDUs will follow, and can be used in the case 
that the link quality map cannot be transmitted in a single LCH PDU. 

The encoding of RLC_CALIBRATION_LINKQUALITYMAP is the same for partial and complete link quality maps, 
but partial RLC_CALIBRATION_LINKQUALITYMAP shall be transmitted on DL DCCH to the sender-WT of the 
report whereas complete RLC_CALIBRATION_LINKQUALITYMAP shall be broadcast on DL RBCH. 



ETSI 



44 



ETSI TS 101 761-4 V1.1.1 (2000-06) 



6.6 



DLC User Connection Control 



6.6.1 Fixed slot allocation for DM 



MSC Direct _Link_Multicast_Setup_ 



CC initiated 



n is the number of 
joined multicast 



WT_AS SOC IATED_WITH_C C 



Mil ticast GroupJoin 



Senderinitiated |\ 



Di rec t_Iink_Multicas t_ 
_Set up_S enderj rit iate d 



loop <l,n> Direct_Link_Milticast_ 
_Setup_CC_ initiated 



Di rec t_Iink_Multicas t_ 
_Comect_c cm pie tion 



MULTICAST jX>NNECTION_ESTABLISHED 



peer_mac_id i s t he 
mutlticast macjd 

source-mac-id is the mac-id 
of the multicast sender 



The CC setup connections 
with all terminals that have 
joined the group 



1(1) 



Figure 17: Overview of DiL Multicast Setup 



6.6.2 Multicast in DiL phase 



6.6.2.1 



General 



The Direct Link can also be used for multicast connections. DiL multicast without QoS negotiation is already supported 
by documents TS 101 761-1 [1], TS 101 761-2 [2]. 
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A multicast connection is identified by three numbers: 

• Destination MAC_ID, numbers from 224 to 254 shall be used; 

• Source MAC_ID, mac_id of the WT that is the sender of this group; 

• DLCC_ID=63 shall be used. 

As is shown in Figure 17, the first action for a WT is to join the muticast group by using the RLC_GROUP_JOIN 
message. Then the CC replies with a dynamically selected multicast MAC ID within the range {224, 254}. This MAC 
ID, in conjunction with DLCC ID=63, will be used as a unique identifier for the multicast group. 

A multicast group that does not require QoS parameter negotiation shall start multicast immediately without performing 
the DiL multicast setup procedure specified in the following subclauses. In this case, each WT of a multicast group can 
become the sender of this multicast group at any time. It just needs to send out a RR for DiL UMCH, in which it sets the 
destination MAC ID to the assigned multicast MAC ID, the source MAC ID to its own MAC ID, and DLCC ID to 63. 

Before a WT1 can become a sender of a multicast group which requires QoS parameter negotiation, it shall first run a 
sender-initiated DM_Multicast_Setup procedure with the CC. Before the DM_Multicast_Setup procedure is 
successfully completed, the WT1 shall not begin to transmit data. After the multicast setup initiation by WT1, the CC 
shall forward the multicast setup request message to each multicast receiver WTx that has joined the multicast group. 

The CC can also initiate a DM_Multicast_Setup even if it is not the sender, in that case it has also to send a multicast 
setup request to the sender WT1. Then, the CC shall perform a multicast setup forwarding procedure for each receiver 
WTx of the multicast group. The setup request to the sender WT1 and the setup forwarding to each receiver WTx uses a 
common procedure, which is the same as the setup forwarding procedure used in the sender-initiated case. 

In both sender-initiated and CC-initiated cases, the CC shall send a RLC_DM_MC_CONNECT_COMPLETE message 
to the sender WT1 after it has forwarded all setup request messages to all other WTs of the group. The 
RLC_DM_MC_CONNECT_COMPLETE message shall be sent only when at least min-req-receivers receivers have 
positively acknowledged the multicast setup request, min-required-receivers is a parameter in the 
RLC_DM_MC_SETUP message, which will be set by the initiating WT, or the CC. 

Another parameter set by the initiating WT is the max_setup_time. This parameter is coded exponentially: 

T _dm_ setup _wt = 4 max - se,u " - lime [MacFrames } 

After transmitting the first RLC_DM_MC_SETUP message to a receiver WTx, the CC starts the timer T_dm_setup_wt. 
If more than or equal to min_required_receivers WTs have completed the setup procedure until the timer 
T_dm_setup_wt expires, the multicast connection is established. That confirmation is given by the CC to the sender 
WT1 by sending it a RLC_DM_MC_CONNECT_COMPLETE message. Then, the sender WT1 is allowed to send data 
in the specified multicast DUC. 

If a terminal responds to the CC after the connection setup has finished it is allowed to receive the multicast DUC, 
although the earlier data might be lost for this WT. If a terminal joins the group after the setup procedure is completed, it 
shall wait until the CC informs it of the ongoing multicast connection. The CC shall inform later joining WTx of the 
connection parameters by performing the setup forwarding procedure for the joining receiver WTx. 

The parameters of an established multicast connection can be modified by a DM_Multicast_Modify procedure. The 
DM_Multicast_Release procedure is used to release an established multicast connection. 

DiL multicast setup is mandatory for multicast groups which make use of Fixed Capacity Assignment specified in 
TS 101 761-1 [1] or Fixed Slot Allocation as specified in subclause 6.6.1 of the present document. 

Referring to the following MSCs the CC can act as the multicast sender WT1, or as one of the multicast receivers WTx. 
In this case all multicast related RLC messages between this WT1 and the CC, or between this multicast receiver WTx 
and the CC, shall be exchanged internally in the CC device. 

All multicast setup, modify and release procedures specified in the following shall use unicast DL DCCH and UL 
DCCH for message exchange between the CC and multicast sender WT1, and between the CC and a particular multicast 
receiver WTx, respectively. As defined for CM, the MAC ID of the uplink and downlink unicast DCCH shall be always 
set to the MAC ID of the WT, which sends or receives this DL or UL DCCH. 
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6.6.2.2 



DiL MULTICAST SETUP, WT-initiated 



When a WT1 of a DiL multicast group wants to become a sender of this multicast group, it shall initiate this procedure if 
the connection requires QoS parameter negotiation. The CC and WT1 may negotiate e.g. FSA or FCA parameters. 
Referring to the following MSC (Figure 18), the source MAC ID is the MAC ID of WT1. This MAC ID is needed for 
the CC to identify the sender WT1. 

For exchanging the link parameters the initiating WT1 transmits a RLC_DM_MC_SETUP message to the CC. The CC 
shall respond by sending the RLC_DM_MC_CONNECT message which is acknowledged by the initiating WT1. In this 
message the CC can modify the QoS parameters proposed by the initiating WT1. 

The direction parameter of the multicast due-descriptor shall be set to simplex-forward for the multicast sender WT1, 
and set to simplex-backward for all multicast receivers WTx. 



MSCDirect_Iink_Multicast_Setup_Sender_initiated 



WT1_ENV 




WT1_RLC 


CC_RLC 




CC_ENV 

















Associated 



DUC_dm_mc_setup_req 



( {DUC-DM-MC-SETUP-ARG) 
T_dm_mc_setup_wt 



DUC_dm_mc_connect_ind 



{DUC-DM-MC-CONNECT-ARG1 ) 
DUC_dm_mc_connect_rsp 



{ DUC-DM-MC-CONNECT- ACK- ARC i ) 



RLC_DM_MC_SETUP 



( { peer_mac_id, 
source_mac_id, 
cl_id, 

duc_ext_ind, 
min_req_receivers, 
cl_conn_attr_length, 
duc_descr_list, 
cl_common_attr) ) 



RLC_DM_MC_CONNECT 



( {peer_mac_id, 
source_mac_id, 
cl_id, 
cl_conn_attr_length, 

duc_descr_list) ) 



pjj:_dm_mc_connect_ack 



( {peer_mac_id, 
source_mac_id, 
cl_id, 

cl_conn_attr_length, 
dlcc_descr_list) ) 



DUC_dm_mc_setup_ind 
( {DUC-DM-MC-SETUP-ARP) 

DUC_dm_mc_connect_req 



{ DUC-DM-MC-CONNECT- ARG) ) 



T_dm_mc_connect_cc 



DUC_dm_mc_connect_cnf 



( { DUC-DM-MC-CONNECT- ACK- ARG 



Figure 18: MSC Direct_Link_Multicast_Setup_WT_CC 
Table 14: RLC-DM-MC-SETUP 



RLC-DM-MC-SETUP-ARG::= SEQUENCE { 


rlc-pdu-type 


RLC-HE-LCH-PDU-TYPE, 


extension-type 


EXTENSION-TYPE 


peer-mac-id 


MAC-ID, 


source-mac-id 


MAC-ID, 


cl-id 


CL-ID, 


duc-ext-ind 


BOOLEAN, 


min-req-receivers 


INTEGER(0..255), 


cl-conn-attr-length 


INTEGER(0..31), 


duc-descr-list 


DUC-DESCR-LIST, 


cl-common-attr 


CL-COMMON-ATTR } 



The parameter source-mac-id is used to identify the sender WT1 in the case of a sender-initiated connection setup. In the 
case of a CC-initiated connection setup this parameter is used to inform a WT1 that it is to become the sender. 
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Table 15: RLC-DM-MC-CONNECT 



RLC-DM-MC-CONNECT-ARG::= SEQUENCE { 


rlc-pdu-type 


RLC-HE-LCH-PDU-TYPE, 


extension-type 


EXTENSION-TYPE 


peer-mac-id 


MAC-ID, 


source-mac-id 


MAC-ID, 


cl-id 


CL-ID, 


cl-conn-attr-length 


INTEGER(0..31), 


duc-descr-list 


DUC-DESCR-LIST} 



Table 16: RLC-DM-MC-CONNECT-ACK 



RLC-DM-MC-CONNECT-ACK-ARG::= SEQUENCE { 


rlc-pdu-type 


RLC-HE-LCH-PDU-TYPE, 


extension-type 


EXTENSION-TYPE 


peer-mac-id 


MAC-ID, 


source-mac-id 


MAC-ID, 


cl-id 


CL-ID, 


cl-conn-attr-length 


INTEGER(0..31), 


dlcc-descr-list 


DUC-DESCR-LIST} 



The sender-initiated setup procedure in Figure 18 shall be followed by a setup forwarding procedure for each multicast 
receiver, as is shown in Figure 19. The CC forwards the RLC_DM_MC_SETUP message to each multicast receiver 
WTx. The peer MAC ID in the setup procedure's messages shall be set to the MAC ID of the multicast group, and 
source MAC ID set to the MAC ID of WT1. 



MSC Direct_Link_Multicast_Setup_CC_initiated 



\ 



WT includes all multicast receivers WTx and it may 
include the multicast sender WT1 if the connection is sender initiated 



WT_ENV 




WT_RLC 




CC_RLC 




CC_ENV 



















{DUC(-DM 



DUC_dm_mc_setup_ind 



Associated 



RLC_DM_MC_SETUP 



DUC_dm_mc_setup_req 



(DUG-DM- C-SETUP-ARG) ) 



( {peer_mac_id, 
source_mac_id, 
cl_id, 
duc_ext_ind, 
min_req_receivers, 
cl_conn_attr_length, 
duc_descr_list, 
cl_common_attr) ) 



^{DUC-DM-MC-SETUP-ARG) ) 
T_dm_mc_setup_cc 



DUC_dm_mc_connect_req 



RLC_DM_MC_CONNECT 



( {DUC-DM-MC-CONECT-ARP) 

( { peer_mac_id, 
source_mac-id, 

T_dm_mc_connect_wt cl_id, 

cl_conn_attr_length, 
duc_descr_list) ) 



DUC dm mc connect ind 



RLC_DM_MC_CONNECT_ACK 



( {DUC-DM-MC-CONNECT-ARPI 
DUC_dm_mc_connect_rsp 



E'UC_dm_mc_connect_cnf 



MC-CONNECT-ACK- ARG } ) 



{DUGE-DM-MC-CONNEC-ACK-ARG} ) 

( { peer_mac_id, 
source_mac_id, 
cljd, 
cl_conn_attr_length, 

dlcc_descr_list) ) 



DUC_established 



Figure 19: MSC Direct_Link_Multicast_Setup_forwarding 
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The CC then waits for the multicast receivers to respond. If one or more multicast receivers do not respond within 
max_setup_time, the CC may retransmit the RLC_DM_MC_SETUP message to each of those multicast receivers. 
Further repetitions are also possible. 

After min-req-receivers receivers have accepted the multicast setup within max-setup-time, the CC shall respond to 
WTx by sending RLC_DM_MC_CONNECT_ACK messages. Otherwise, it shall abort the multicast connection setup 
by performing a CC -initiated multicast release for each receiver WTx that is already involved in the setup procedure, 
and the sender WT1. 

If at least min_required_receivers WTx respond positively within max-setup-time, which has been exchanged between 
initiating WT1 and CC, the multicast connection is accepted by the CC. The CC transmits a 
RLC_DM_MC_CONNECT_COMPLETE message to the initiating WT1. The initiating WT1 shall respond with a 
RLC_DM_MC_CONNECT_COMPLETE_ACK message (Figure 20). 



MSC Direct_Link_Multicast_Connect_completion 

WT1_ENV WT1_RLC 



CC_RLC 



CC_ENV 



DUC_dm_mc_conn_complete_ind 



( DUC-DM-MC_COMPLETE-ARG) 
DUC_dm_mc_conn_complete_rsp 



(DUC-DM-MC-C OMPLETE- ACK-ARG ) 



RLC_DM_MC_CONNECT_ COMPLETE 



( {peer -mac-id, 
source-mac-id, 
dice -id-list}) 



RLC_DM_MC_CONNEC T_ COMPLETE_AC K 



({peer -mac-id, 
source-mac-id}) 



DUC_dm_mc_conn_complete_req 



( DUC-DM-COMPLETE-ARG) 



T_dm_mc_connect_cmpt_cc 



DUC_dm_mc_conn_complete_cnf 



(DUC-DM-MC-C OMPLETE- ACK-ARG ) 



Multicast_DUC_establisred 



Figure 20: MSC Direct_Link_Multicast_Setup_Completion 



Table 17: RLC-DM-MC-CONNECT-COMPLETE 



RLC-DM-MC-CONNECT-COMPLETE-ARG::= SEQUENCE { 



rlc-pdu-type 

extension-type 

peer-mac-id 

source-mac-id 

dlcc-id-list 



RLC-HE-LCH-PDU-TYPE, 

EXTENSION-TYPE 

MAC-ID, 

MAC-ID, 

DLCC-ID-LIST} 
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Table 18: RLC-DM-MC-CONNECT-COMPLETE-ACK 



RLC-DM-MC-CONNECT-COMPLETE-ACK-ARG::= SEQUENCE { 
rlc-pdu-type RLC-HE-LCH-PDU-TYPE, 
extension-type EXTENSION-TYPE 
peer-mac-id MAC-ID, 

source-mac-id MAC-ID} 



6.6.2.3 DiL MULTICAST SETUP for a new joining WT 

This clause describes the cases that a new WT has joined the group and is informed by the CC of the multicast 
connection parameters. 

The CC shall re-use the setup forwarding procedure depicted in Figure 19 after a new WT has joined the multicast group 
using the JOIN procedure to let the new WT know the MAC ID of the multicast sender and other connection 
parameters. After this multicast setup procedure is completed, this new WT might not be able to receive the multicast 
data. In this case, it may perform the DiL Power Control procedure for multicast/broadcast to request the multicast 
sender to increase the transmit power. No further action is specified, if the new WT still cannot decode the multicast 
data correctly. 

The multicast setup forwarding procedure for a new joining multicast receiver is transparent to the multicast sender. 

6.6.2.4 DiL MULTICAST SETUP, CC initiated 

This clause describes the case that a new multicast connection from a sender WT1 (also the CC may be the sender) to 
the multicast group (also the CC may be member of this group) is to be established by the CC. 

The CC-initiated multicast uses the procedure in Figure 19 for the multicast sender and all receivers. The CC shall first 
transmit a RLC_DM_MC_SETUP to the sender WT1, at this stage the sender can negociate parameters of the 
connection with the CC. The peer_MAC_ID parameter in the RLC_DM_MC_SETUP message shall be set to the MAC- 
ID of the multicast group. The sender WT1 is informed that it is to become the sender by looking at the source_mac_id 
field in the RLC_DM_MC_SETUP message, which is set to the MAC ID of WT1. 

The sender WT1 shall respond with a RLC_DM_MC_CONNECT and the CC shall send the acknowledgement to 
confirm parameters. Then the CC shall repeat the setup forwarding procedure in Figure 19 for each joined multicast 
receiver WTx. 

The CC then waits for WTs to respond. If one or more multicast receiver WTs does not respond within max_setup_time, 
the CC may retransmit the RLC_DM_MC_SETUP message using a downlink unicast DCCH. Further repetitions are 
also possible. The multicast sender WT1 shall respond positively within max_setup_time. Otherwise, the CC-initiated 
DiL_Multicast_Setup procedure fails. 

If at least min_required_receivers WTs (the sender excluded) of the multicast group respond within max_setup_time to 
the RLC_DM_MC_SETUP message, the multicast connection is accepted by the CC. A negotiation of max_setup_time 
is not needed, if the CC is the sender of the multicast connection. If for any reason the multicast setup fails, the CC shall 
abort the multicast setup procedure by performing a CC-initiated multicast release for the multicast sender and each 
multicast receiver already involved in the setup procedure. 



ETSI 



50 



ETSI TS 101 761-4 V1.1.1 (2000-06) 



If the sender and min_req_receivers receivers have accepted the multicast setup, the Multicast Setup Completion 
procedure in Figure 20 shall be finally performed. The CC shall transmit a RLC_DM_MC_CONNECT_COMPLETE 
message to the sender WT1 or to itself (if CC is sender), which shall be responded by a 
RLC_DM_MC_CONNECT_COMPLETE_ACK message. 

6.6.2.5 MODIFY MULTICAST 

The modification of the multicast connection characteristics can be sender-initiated or CC-initiated. If it is sender- 
initiated, the multicast sender WT1 shall send a RLC_DM_MC_MODIFY_REQ to the CC. This triggers the CC to 
perform multicast modify by sending RLC_DM_MC_MODIFY to the multicast sender WT1 (Figure 21) and to each of 
the multicast receivers WTx (Figure 22). The RLC_DM_MC_MODIFY contains a parameter field start-mac-frame, 
which tells all WTs when the modified multicast shall start. If it is CC-initiated, the CC shall perform the multicast 
modify procedure without the request from the multicast sender. In this case, the procedure in Figure 22 shall also 
performed for the multicast sender. 

A timer T_rsp is set similar to the multicast setup procedure. If not all WTs have responded by sending a 
RLC_DM_MC_MODIFY_ACK until the timer expires the CC shall retransmit the RLC_DM_MC_MODIFY message 
on DL DCCH to each of the concerned WTs. 

The Multicast Setup Completion procedure shall not be used in case of modifying a multicast DUC. 

The connection parameters are changed after all WTs of the multicast group have responded or all repetitions to the not 
responding WTs have finished. 

If the sender does not accept the RLC_DM_MC_MODIFY message from the CC, the CC shall release the multicast 
connection for all involved WTs. If one or more multicast receiver does not accept the RLC_DM_MC_MODIFY 
message from the CC, the CC shall release the connection for these receivers. In the latter case it shall only release the 
multicast connection for all other WTs (including the sender), if the number of the remaining receivers is less than 
min_required_recei vers . 

The exact start point to change the multicast connection is given by the start-mac-frame parameter, which is sent from 
the CC to all multicast WTs. start-mac-frame is the absolute MAC Frame number as determined by the MAC Frame 
Counter in the BCCH. To overcome the 4 bit limitation of the MAC Frame Counter parameter in BCCH, start-mac- 
frame is furthermore offset by a MAC Frame Cycle parameter, which gives the number, the MAC Frame Counter value 
repeats in BCCH after the reception of the RLC_DM_MC_MODIFY message (1 repetition corresponds to 16 MAC 
frames). The reference for the offset is the MAC frame the RLC_DM_MC_MODIFY PDU is received. That means that 
the RLC instance shall know in which MAC frame it received the RLC_DM_MC_MODIFY message in order to 
determine the right MAC frame to change the multicast connection. The CC should set start_mac_frame sufficiently late 
to allow all WTs to be prepared for this change. 

start_mac_frame is 16 bits long. Its 4 MSB are used to encode the MAC Frame Counter value, and its 12 LSB are used 
to encode the MAC Frame Cycle value. Either coding is in binary. With this length of the start_mac_frame parameter 
the maximum time between the RLC_DM_MC_MODIFY PDU and the multicast connection change is 131 seconds. 

EXAMPLE: start_mac_frame = 00 1 00000000000 1 

The MAC frame to change the multicast connection is the second time (because of offset = 
000000000001) the MAC Frame Counter in the BCCH shows the value 0010 after the reception of the 
RLC_DM_MC_MODIFY PDU. 

If a multicast connection is used for FSA, the start_mac_frame value in the RLC_DM_MC_MODIFY message shall be 
equal to the start-mac-frame value in the FSA-RG parameter, which is also included in RLC_DM_MC_MODIFY. 
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MSC Direct_Link_Multicast_Modify_Sender_initiated 



WT1_ENV 




WT1_RLC 













WT1 is multicast 
sender. 



Multicast established 



CC_RLC 




CC_ENV 











({D UC-DM -MC-M OD IFYREQ-ARG} ; 
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Figure 22: MSC Direct_Link_Multicast_Modify_CC_WT 
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Table 19: RLC-DM-MC-MODIFY-REQ 



RLC-DM-MC-MODIFY-REQ-ARG::= SEQUENCE { 



rlc-pdu-type 

extension-type 

peer-mac-id 

source-mac-id 

cl-conn-attr-length 

duc-descr-list 



RLC-HE-LCH-PDU-TYPE, 

EXTENSION-TYPE, 

MAC-ID, 

MAC-ID, 

INTEGER(0..31), 
DUC-DESCR-LIST} 



Table 20: RLC-DM-MC-MODIFY 



RLC-DM-MC-MODIFY-ARG::= SEQUENCE { 


rlc-pdu-type 


RLC-HE-LCH-PDU-TYPE, 


extension-type 


EXTENSION-TYPE, 


peer-mac-id 


MAC-ID, 


source-mac-id 


MAC-ID, 


start-mac-frame 


START-MAC-FRAME, 


cl-conn-attr-length 


INTEGER(0..31), 


duc-descr-list 


DUC-DESCR-LIST} 



Table 21 : RLC-DM-MODIFY-ACK 



RLC-DM-MC_MODIFY-ACK-ARG::= SEQUENCE { 


rlc-pdu-type 


RLC-HE-LCH-PDU-TYPE, 


extension-type 


EXTENSION-TYPE, 


peer-mac-id 


MAC-ID, 


source-mac-id 


MAC-ID, 


start-mac-frame 


START-MAC-FRAME, 


cl-conn-attr-length 


INTEGER(0..31), 


dlcc-descr-list 


DUC-DESCR-LIST} 



6.6.2.6 RELEASE MULTICAST 

The release can be CC-initiated or WT-initiated, where WT can be the multicast sender or one of the receivers. In case 
of a CC-initiated release the CC shall transmit a RLC_DM_MC_RELEASE to the WT, which it wants to disconnect 
from the multicast. The WT shall reply with RLC_DM_MC_RELEASE_ACK.. If the sender has been released, the 
CC-initiated multicast release as shown in Figure 23 shall be repeated for each multicast receiver to stop its receive 
operation. 

In case of a sender-initiated release, the sender of the multicast group shall send a RLC_DM_MC_RELEASE to the CC. 
The CC shall send back a RLC_DM_MC_RELEASE_ACK message to the sender (Figure 24). The CC shall then start 
the CC-initiated multicast release in Figure 23 for each multicast receiver to stop its receive operation. If a multicast 
receiver initiates the WT-initiated release in Figure 24, the CC shall acknowledge by replying with 
RLC_DM_MC_RELEASE_ACK. In this case, the CC shall only release the multicast connection for all other WTs 
(including the sender), if the number of the remaining receivers is less than min_required_receivers. 



ETSI 



53 



ETSI TS 101 761-4 V1.1.1 (2000-06) 



MSC Direct_Link_Multicast_Release_CC_initiated 
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Figure 24: MSC Direct_Link_Multicast_Release_WT_CC 
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Table 22: RLC-DM-MC-RELEASE 



RLC-DM-MC-RELEASE-ARG::= SEQUENCE { 



rlc-pdu-type 

extension-type 

peer-mac-id 

source-mac-id 

dlcc-id-list 

release-cause 



RLC-HE-LCH-PDU-TYPE, 

EXTENSION-TYPE, 

MAC-ID, 

MAC-ID, 

DLCC-ID-LIST, 

RELEASE-CAUSE} 



Table 23: RLC- DM-MC- RELEASE-ACK 



RLC-DM-MC-RELEASE-ACK-ARG::= SEQUENCE { 



rlc-pdu-type 
extension-type 
peer-mac-id 
source-mac-id 
dlcc-id-list 



RLC-HE-LCH-PDU-TYPE, 
EXTENSION-TYPE, 
MAC-ID, 
MAC-ID, 
DLCC-ID-LIST} 



6.7 Dynamic CC Selection 

The dynamic CC Selection ensures that within one radio cell or subnet only one CC is established. It is performed in a 
decentralized and autonomous way by each CC-capable device. The selection does not take into account the best 
position or the best capabilities of a CC-capable device because the necessary measurements are not available at this 
stage. The CC is selected at random based on a contention process. However, the user can prevent an unfavourably 
located CC-capable device from being the CC by disabling this CC-capable device to participate in the CC selection 
process. All CC-capable H/2-HDs shall support dynamic CC selection. Besides, all CC-capable H/2-HDs shall indicate 
to the user by an implementation specific means whether they are in the CC selection phase, or acting as the CC. 

6.7.1 Principle 

Each CC-capable device first tries to become a WT. The first step is to scan all available frequencies for already running 
CCs (initial scanning process, see 6.7.2). If no CC has been found or association to the CCs is not possible (e.g. it is the 
CC of the neighbour or a CC/AP without HE capability) each CC-capable device shall try to become a CC by 
performing the CC Selection protocol. Each CC-capable shall also have a user interface, which enables the user to 
disable the CC Selection function, if the corresponding CC-capable device is to be excluded from the CC selection 
process. A CC-capable device with disabled CC Selection function shall only be able to act as a basic WT. 

In order to prevent multiple CC-capable devices from becoming CC, a CC collision resolution, i.e. the CC Selection 
protocol, is performed. The basic idea is that each CC-capable device transmits a "Probing Beacon" from time to time 
and senses the channel in between. The Probing Process, i.e. transmitting of Probing Beacons and sensing the Probing 
Channel to detect beacons from other devices, is interrupted for frequency scanning phases in which all other available 
frequencies are scanned for another CC-capable device. Each CC-capable device which senses a "Probing Beacon" 
withdraws from the CC Selection, performs a back-off and starts with the initial scanning process again. This may result 
in a new CC Selection process. 

After a predefined time the CC-capable device which has not sensed anything survives and becomes CC. Of course it is 
not possible to resolve all collisions with this protocol. There is still a residual collision probability. 

6.7.2 Initial Scanning Process 

The scanning of frequency channels is not defined in the present document. For detection and selection of a CC it is 
necessary to define some minimum requirements on the scanning process. 

In order to find a CC the initial frequency scanning is performed first, e.g. if a H/2-HD is powered on. The CC selection 
process is started only in the case no CC has been found. 
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A CC-capable device in the initial scanning phase shall: 

• Scan all available frequencies for other CC. 

• Scan each frequency for at least two MAC Frames = 4 ms. 

• Measure and store the interference level on all available frequencies. 

• Store all successfully received BCCH. 

• Decode the downlink RBCH, if a BCCH has been received successfully. 

• Try association with all detected CCs. If a detected CC does not support the HE, the association with this CC 
shall be aborted. 

If Association has been successful with any CC the CC Selection for this CC-capable device is done. This device 
becomes a WT. 



If no BCCH has been detected, or no Association has been successful the CC-capable device starts the CC Collision 
Resolution procedure, see subclause 6.7.4. 

NOTE: An aborted association with a non HE-compliant CC is an unsuccessful association. The frequency used 
by this CC shall be excluded from the following CC Collision Resolution process. A re-association to this 
CC after the completion of CC Collision Resolution is optional, if no other CC with HE capability can be 
found, and the scanning CC-capable device decides not to become a CC. 

A manufacturer can implement on a H/2-HD different usage profiles. By selecting a non HE-compliant 
usage profile, the user can configure a H/2-HD as a non HE-compliant device to be preferably associated 
with a non HE-compliant CC. 



6.7.3 Definitions 



6.7.3.1 Probing Phase 



CC Probing Frame F P 



BCCH 



/ TTA 
Start 

Transmission 



Figure 25: CC Probing Frame 

Figure 25 shows a CC Probing Frame F P . Within each CC Probing Frame a CC-capable device transmits one CC 
Probing BCCH (for the contents of the Probing BCCH see 7.6). Inside F P the beginning of the transmission is defined by 
the Start_Transmission time. Thus a CC Probing BCCH can overlap into the next CC Probing Frame. This is shown in 
Figure 26. 



CC Probing Frame F P 



CC Probing Frame F P 




Figure 26: Start Transmission of CC Probing BCCH 
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If the CC Probing BCCH overlaps into the next CC Probing Frame, the next start of transmission is limited to the range 
from the end of transmission to the end of F P . In Figure 26 this is called "Next Start of Transmission". 

6.7.3.2 Frequency Scan Phase 



Period P 




Probing 
Frequency 

Frj 



Frequency 
Frequency SCAN 

Switching xime XscAN 

Time Tps 

Figure 27: Probing Period consisting of Probing Phase and Frequency Scan Phase 

Figure 27 shows the definition of a Probing Period P. Each Probing Period consists of several CC Probing Frames 
(Probing Phase) and a Frequency Scan Phase. During the Frequency Scan Phase the CC Probing is stopped for the CC- 
capable device which performs the Frequency Scan. 

Within one Probing Period a CC-capable device shall scan all other frequencies for CC Probing BCCH. The Frequency 
Switching Time T FS is the maximum time it takes to switch to another frequency channel. This time is defined in the 
TS 101 475 [3]. The Frequency Scan Time TScan determines the time a CC-capable device in the CC Selection process 
shall scan a frequency channel for a CC Probing BCCH. The CC-capable device shall switch to a new frequency 
immediately after scanning the previous one. 

After a CC-capable device returns from a Frequency Scan Phase it continues with CC Probing Frames, if no BCCH has 
been detected during the Frequency Scan Phase. The definition and random calculation of the start time of the 
Frequency Scan Phase (timer Start_ Frequency_SCAN) per Probing Period is similar to the start time of the Beacon 
transmission (timer Start_Transmission) per CC Probing Frame. 



6.7.3.3 



Parameter, Timer 



Table 24: CC Selection Parameters 



Parameter 


Value 


CC Probing Frame F P 


500 us 


Frequency SCAN Time TScan 


2 * F P = 1 ms 


CC Probing Period P 


100 ms 


Number of Periods 


10 


Total Time for CC Collision Resolution 


1 s 


Collision Probability 


5*10" 5 = 0.005%= 1/20000 
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The Timer for Start Transmission and Start Frequency SCAN are set as follows: 
Start Transmission: 

• Start_Transmission is randomly chosen with a uniform distribution within [min_Start_Transmission, 
CC_Probing_Frame F P ); 

• min_Start_Transmission = max (0, previous_Start_time+BCCH_Transmission_duration - F P ); 

• previous_Start_time = for the first transmission in the first Probing Period and after each Frequency Scan 
Phase; 

• previous_Start_time = Start_Transmission, after the selection of Start_Transmission; 

• BCCH_Transmission_duration = 48 |is (including preamble and two transceiver turnaround times). 
Start Frequency SCAN: 

• Start_Frequency_SCAN is randomly chosen with a uniform distribution within [min_Start_Frequency_SCAN, 
Period P); 

• min_Start_Frequency_SCAN = max (0, previous_Start_Frequency_SCAN_time+Frequency_SCAN_duration - 

P); 

• previous_Start_Frequency_SCAN_time = for the first frequency Scanning Phase; 

• previous_Start_Frequency_SCAN_time = Start_Frequency_SCAN, after the selection of 
Start_Frequency_SCAN; 

• Frequency_SCAN_duration = 37 ms (for a total number of 18 available frequency channels - the Probing 
Channel is excluded - and a frequency switching time of 1 ms TS 101 475 [3]. 
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6.7.4 



Protocol 



If no Association has been successful the CC -capable device shall choose one appropriate frequency channel. This 
frequency channel is called CC Probing frequency. 

The CC-capable device shall: 

Maintain a CC Probing Frame timer. 

- Maintain a Start_Transmission timer. 

- Maintain a CC Probing Period timer. 

- Maintain a Start_Frequency_SCAN timer. 

- Maintain a Period counter. 

Select a CC Probing BCCH transmission start time (Start_Transmission) each time the CC Probing Frame 
timer expires, or after the completion of the Frequency Scan Phase, if no BCCH has been detected; Set the 
CC Probing Frame Timer to F P . 

- Select a frequency scanning start time (Start_Frequency_SCAN) each time the CC Probing Period timer 
expires, set the CC Probing Period Timer to P and increase the Period_Counter by one. 

- Transmit a CC Probing BCCH, if the CC Probing BCCH transmission start time is reached. 

Stop CC Probing and Start the frequency scanning procedure, if the frequency scanning start time is reached. 
Sense each frequency channel excluding the last Probing Frequency for other Probing BCCH. 

- Stop the CC Selection Procedure and start a back-off of (1 s), if a Probing BCCH or a regular BCCH is 
received successfully. All timers are stopped. After the back-off has expired the CC-capable device starts 
again with the initial scanning process trying to find a CC in operation and to associate to it, see subclause 
6.7.2. If no association is possible the CC Selection Protocol is performed again. 

- Start CC operation, if Period_Counter = Number of Periods. 



During the frequency scanning each frequency channel except the CC Probing frequency channel is scanned for CC 
Probing BCCH. The order of the frequency channels is randomly chosen. The selection procedure has to ensure that 
each frequency is scanned once per Frequency SCAN. 

Each frequency is scanned for 1 ms. If no BCCH has been detected after 1 ms the CC-capable device switches to the 
next frequency. If no more frequencies have to be scanned in the current Period, the CC-capable device continues with 
CC Probing Frames. 



The CC Responsibility Handover is necessary in case that the current CC is no longer able or intended to carry the CC 
responsibility for the subnet. Reasons for a CC Responsibility Handover, that are out of the scope of the present 
document, can be e.g. switch off of the WT currently carrying the CC responsibility, a bad connectivity of the current 
CC, power constraints of the CC, etc. Only old CC-initiated CC Handover is considered in the present document. 

The CC Responsibility Handover protocol guarantees a soft handover, in which case all DiL connections are maintained 
during and after the handover process. The handover is transparent to the network and to the other WTs as far as DiL 
connections are concerned. The same applies to the user plane of the two terminals involved in the CC Responsibility 
Handover. The old CC becomes a WT and keeps its own DiL connections. All connections in CM are nevertheless 
released during CC Responsibility Handover. The CC Responsibility Handover concerns mainly MAC control and RLC 
instances of the control plane of the current CC. 



6.7.4.1 



Frequency scanning 



6.8 



CC Responsibility Handover 
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To seamlessly maintain all running DiL connections, the RLC instances of the current CC have to be transferred to the 
CC-capable WT that is going to take over the CC responsibility. This CC-capable WT is called CC-candidate. All 
relevant RLC information is directly transmitted from the current CC to the CC-candidate. This is done during ongoing 
operation on the current frequency. No MAC control information is transferred during or after the CC Handover 
process. The new CC may build its own MAC database by either listening to RRs of the WTs and decoding RGs in the 
frames before CC Handover or by polling the WTs for RRs in the frame(s) after CC Handover. After successful 
preparation of the CC Handover between the old and the new CC, the new CC takes over BCCH transmission 
seamlessly. 

Support of CC Responsibility Handover is optional for CC-capable H/2-HDs. 

6.8.1 Basic Procedure 

The basic procedure of CC Responsibility Handover can be depicted from Figure 28. 



CC Handover Initiation 




r 


Request to CC-candidate 




T 


Inform all WTs about forthcoming CC Handover 




T 


Stop RLC 




r 


Inform CLs which prepare for CC Handover 




T 


Transfer RLC Data to CC-candidate 




r 


Instruct CC-candidate to start BCCH transmission 




T 


Inform CLs and other WTs about successful Handover 



Figure 28: Basic Procedure of CC Handover 



In case of a CC initiated CC Responsibility Handover the handover procedure is triggered by an internal request. 

• As the CC Handover should be as much as possible transparent to the higher layers the CC Handover is triggered 
by an implementation specific algorithm inside the RLC layer. This is indicated by the CCH_cc_ho_request_req 
primitive which is generated under control of the RLC (see Figure 29). 

After reception of the CC Handover Request the current CC has to select a CC-candidate from the list of CC-capable 
WTs. As an example, this selection can be done based upon the global connectivity map, see subclause 6.5.4. 

The selected CC-candidate HL2/HD is informed, that it has been chosen to take over the CC functionality. This implies 
the following message exchanges: 

• A Handover Request message is sent out to the selected CC-Candidate. The selected CC-candidate is requested 
to prepare itself for the CC Handover. RLC_CC_HO_REQUEST is transmitted on DL DCCH. 
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• The CC-candidate informs its RLC environment about the CC Handover Request by a CC Handover Indication. 

• The RLC environment of the CC-candidate answers with a CC Handover Response. 

• Then the selected CC-candidate WT acknowledges that it is prepared for the CC Handover. This 
RLC_CC_HO_ACK PDU is transmitted on UL DCCH. 

The next step consists in informing all WTs about the forthcoming CC Handover. Sleeping WTs are not woken up. 
Instead, the sleeping intervals of these WTs are transferred together with the other RLC data to the CC-candidate in a 
later stage of the procedure (see below). 

• The CC sends out a broadcast message on DL RBCH to inform all WTs about the forthcoming CC Responsibility 
Handover (RLC_CC_HO_NOTIFY). Even CC Handover is optional for CC -capable devices, the 
RLC_CC_HO_NOTIFY shall be supported by all H/2-HDs. 

In response, the RLC entities of all WTs in the subnet are stopped. This means that no new Association, DUC Set- 
up/modify/release, power saving and DFS requests are started. The RLC entities of the WTs are set into a special state 
RLC_Stopped_WT which only occurs during CC Handover. 

• At the same time all ongoing Association, DUC Set-up/modify/release and power saving requests are aborted by 
the current CC. 

The RLC entities within the CC are set into the RLC_Stopped state. New requests are not processed by the CC any 
more. During CC Handover no Association, DUC Set-up/Modify, Sleep or DFS request is possible to ease the 
operation. 

The fifth step in Figure 28 concerns the influence of the CC Handover on the higher layers, which may have to prepare 
for the CC Handover. 

• After the positive acknowledgement of the CC-candidate the current CC sends out a CCH_start_cl_ho_ind 
primitive to the environment. This primitive may be used by the CLs as information of the forthcoming CC 
Handover. 

After reception of the CCH_start_cl_ho_ind the CLs may prepare themselves for the CC Responsibility Handover, if 
this is necessary. They may e.g. perform a CL handover, if the current CC also contains a centralized decision making 
entity and database in the respective CL. It is up to the CLs of the old CC to inform the other WTs (including the CC- 
candidate) on CL level about the ongoing CC Handover on RLC level, if necessary. The main part of the CC Handover 
procedure on RLC level, the transmission of the RLC data to the CC-candidate, may not be started unless the CL 
procedures are finished. 

• After a CCH_start_cl_ho_rsp primitive is received from the environment, all connections in CM are released by 
the CC. 

DiL connections relayed by the current CC are kept. They are only released in case that the CC is leaving the network 
(e.g. switch-off). 

• Then the transfer of data, states and timers of the RLC to the CC-candidate is started by a CCH_start_cc_req 
primitive from the RLC environment. For this purpose DL DCCH is used between the CC and the CC-candidate 
(ordinary RLC operation). The RLC instances in the new CC are set to the same state as in the old CC. For a 
detailed description of the data transfer see subclauses 6.8.3 and 7.8. 

• The CC data PDUs are transmitted by means of a "Go-back-n" ARQ mechanism. A certain number of 
RLC_TRANS_CC_DATA PDUs are acknowledged by the CC-candidate with a 
RLC_TRANS_CC_DATA_ACK PDU on UL DCCH. 
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The CC-candidate is now ready to take over the CC functionality. To enable a smooth handover, the old CC informs the 
new CC when to start with a BCCH transmission. This is done by a handshake message: 

• The current CC sends a RLC_START_CC message to the CC-candidate using DL DCCH and including an 
indication when to start with BCCH transmission (start-mac-frame). The parameter start-mac -frame gives the 
exact MAC Frame the new CC shall start CC operation, start-mac-frame is the absolute MAC Frame number as 
determined by the MAC Frame Counter in the BCCH. To overcome the 4 bit limitation of the MAC Frame 
Counter parameter in BCCH, Start MAC Frame is furthermore offset by a MAC Frame Cycle parameter, which 
gives the number, the MAC Frame Counter value repeats in BCCH after the reception of the Start CC message (1 
repetition corresponds to 16 MAC frames). The reference for the offset is the MAC frame the RLC_Start_CC 
PDU is received. That means that the RLC instance shall know in which MAC frame it received the 
RLC_Start_CC in order to determine the right MAC frame to start CC operation. The CC-candidate shall be able 
to start the CC operation at latest 2 MAC frames after the arrival of the RLC_Start_CC message. 

Start-mac-frame is 16 bits long. Its 4 MSB are used to encode the MAC Frame Counter value, and its 12 LSB are used 
to encode the MAC Frame Cycle value. Either coding is in binary. With this length of the start-mac-frame parameter the 
maximum time between the RLC_START_CC PDU and the CC Handover is 131 seconds. 

EXAMPLE: start-mac-frame = 0010 000000000001 

The MAC frame to start CC operation is the second time (because of offset = 000000000001) the MAC 
Frame Counter in the BCCH shows the value 0010 after the reception of the RLC_Start_CC PDU. 

• The CC-candidate sends a CCH_start_cc_ind primitive to the environment. This primitive may be used to inform 
the CLs present in the CC-candidate about the completion of the CC Handover. 

• Upon recption of a CCH_start_cc_rsp the CC-candidate sends a RLC_START_CC_ACK message to the old CC 
using UL DCCH. 

The new CC starts at the time a BCCH is expected. Thus the synchronization is nearly maintained (apart from some 
jitter due to the ±20 ppm BRAN clock drift in old and new CC). The new CC shall use maximum transmit power in the 
first frames after take over of the CC responsibility. When the new CC is ready to take new RLC requests, it enables the 
RLC instances again. 

• The new CC informs the WTs about the successful CC Responsibility Handover by sending out a 
RLC_CC_START_OPERATION Broadcast message on DL RBCH. On reception of 
RLC_CC_START_OPERATION the WTs are allowed to start again with new RLC requests. Even CC 
Handover is optional for CC-capable devices, the RLC_CC_START_OPERATION shall be supported by all 
H/2-HDs. Both CC and WTs may apply an increased power level after reception of the 
RLC_CC_START_OPERATION (because the distance to the CC has changed). 

• At the same time the old CC, which knows the start time of the new CC, informs its RLC environment about the 
take over of the CC responsibility by the new CC using a CCH_start_cc_cnf. 

NOTE: Like for all other procedures, the primitives (between RLC environment and RLC as well as between CLs 
and RLC) defined in this clause are only of informative nature. 

The RRs, or the state of the scheduler are not transmitted to the new CC. Thus the new CC has to take action to get RRs 
from the WTs. The new CC can either listen to RRs and decode RGs in the frames after the first Handover Request 
message and already before sending out the BCCH for the first time or it can poll WTs in the frame(s) after take over of 
the CC responsibility. 

During the whole CC handover process, the ordinary user data transmission including RR, RG, scheduling, Random 
Access, and Random Access Feedback go on as usually for all DiL connections. 

A high level Message Sequence Chart (MSC) of the CC Handover Procedure can be found in Figure 29. 
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MSC CC Handover 



CC_ENV 




CC_RLC 




CC_CAND_RLC 




CC_CAND_ENV 




WT_RLC 























WTs ASSOCIATED TO OLD CC 



CCH_cc_ho_request_req 



T_cc_ho_request_cc 



(mac-id) 



X — 

CCH_cc_ho_request_cnf 



(mac-id) 



RLC_CC_HO_REQUEST 



RLC_CC_HO_REQUEST_ACK 



RLC CC HO NOTIFY 



CCH_cc_ho_request_ind 



(mac-id) 
CCH_cc_ho_request_rsp 



(mac- id) 



Stop_RLC 



CC_abort_all_ongoing_RLC_requests 



CCH start cl ho ind 



CLs_prepare_for_CC_HO 

CCH_start_cl_ho_rsp 



CC Release all UL and DL connections 



CCH_start_cc_req 



(mac-id) 

X- 

trans cc data cc 



RLC 



T start cc cc 



CCH start cc cnf 



(mac-id) 



RLC TRANS CC DATA 



(ext-ind, data) 



TRANS CC DATA ACK 



(sn, rr-flag) 
RLC START CC 



(start-mac- frame) 



RLC START CC ACK 



CCH start cc ind 



(mac- id, start-mac-fram^ ) 
CCH_start_cc_rsp 



(mac-id) 



RLC CC START OPERATION 



Reable RLC 



WTs ASSOCIATED TO NEW CC 



Figure 29: MSC of the CC Responsibility Handover Procedure 
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Table 25: RLC_TRANS_CC_DATA 



RLC-TRANS-CC-DATA-ARG::= SEQUENCE! 
rlc-pdu-type RLC-HE-SCH-PDU-TYPE 
extension-type EXTENSION-TYPE, 
ext-ind EXT-IND, 
data DATA} 



Table 26: RLC TRANS CC DATA ACK 



RLC-TRANS-CC-DATA-ACK-ARG::= SEQUENCE! 
rlc-pdu-type RLC-HE-SCH-PDU-TYPE 
extension-type EXTENSION-TYPE, 
sn SEQUENCE-NUMBER 
rr-flag RR-FLAG 
} 



Table 27: RLC START CC 



RLC-START-CC-ARG::= SEQUENCE! 

rlc-pdu-type RLC-HE-SCH-PDU-TYPE 
extension-type EXTENSION-TYPE, 
start-mac-frame START-MAC-FRAME 

__l 



6.8.2 RLC Data Transmitted During CC Responsibility Handover 

The data to be transmitted from the current CC to the CC candidate falls into two categories: 

• parameters related to all associated H/2-HDs; 

• parameters related to all maintained DiL connections (unicast and multicast). 

No information related to connections in CM shall be transmitted, because these connections are not maintained 
during CC Handover. 

No broadcast specific parameters shall be transmitted, because the CC-candidate has necessarily been member of the 
broadcast group. 

No CC specific parameters shall be transmitted during CC Handover. This is due to the fact that relevant parameters 
like NET ID or AP ID of the old CC are always announced in the BCCH and therefore known to the CC-candidate. The 
new CC takes over the AP ID of the old CC, but all MAC IDs remain unchanged. 

No RR specific parameters shall be transmitted during CC Handover. The reason for this is that all RR specific 
information is related to the same frame, in which this information is transmitted from the old to the new CC. In other 
words, this information is already quite old if the new CC receives it. Another reason for not transmitting the RRs from 
the old to the new CC is, that the probability of error in this transmission is as high as the probability that the CC- 
candidate does not correctly understand a RR, if the CC-candidate is listening to the RRs in the frame(s) before the 
handover. 

If the CC-candidate was not able to listen to the RRs in the frames before handover, there is an interruption from the 
user point of view in the 'loss' of RRs. If the new CC polls all WTs in the first MAC Frame for RRs by granting one 
LCCH to each WT and connection, the interruption is limited to one MAC Frame. 

6.8.2.1 Parameters related to all associated H/2-HDs 

For every WT as well as for the old CC (which becomes a WT) the following set of parameters (Table 28) should be 
transmitted: 
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Table 28: Parameters related to all associated H/2-HDs 



Parameter 


O/M 


Description 


auth-id-pr 


M 


One bit that equals 1 if mt-auth-id is transmitted (resp. present) 


mt-auth-id-type 


O 


The mt-auth-id (4 bits) is of one of the following types: 

ieee, ext-ieee, net-acc-id ordist-name, compressed or generic. 


mt-auth-id 


O 


This is the concrete authentication identifier of the H/2-HD in one of the formats 
mentioned above. It is either 6 octets long in case of an ieee address, 8 octets long 
in case of ext-ieee, 46 octets long in case of net-acc-id or dist-name, 16 octets long 
in case of "compressed" and 92 octets in case of "generic". 


mac-id 


ft A 

M 


This is a 8 bits long unique identifier of the H/2-HD inside one subnet. 


dlc-version-selected 


M 


Version of the DLC protocol (8 bits long) 


rlc-version-selected 


M 


Version of the RLC protocol (8 bits long) 


nr-cl-vid 


M 


1 1 1 x x 1 l_ h 1 r /—\ 1 ■ ■ i 1 ■ xl ll/stll r~\ 1 x x 1 x 1 xl 

Indicates the number N of CLs present within the H/2-HD and at the same time the 
number of cl-vid that follow. The nr-cl-vid field is 3 bits long. 


cl-vid 


ft A 

M 


This parameter consists of a cl-id field (8 bits) and a cl-version field (8 bits), which 
define the id and version of one of the multiple CLs. For every CL present within the 

1— l/9-l— 1 1^ tho f^l-\/iH nQramotor ic trQncmittoH 

n/£. _ nu nit; oi viu paiaiiiuici ib iicuibiinucu. 


ci ii'"\i'"\/"M"ffi^/"'i^ m 
bUppUl lu^tqdlll 


IVI 


VJNt? Ull llldl ULjUdlb 1 II VV 1 bUppUiLb D'f ^JMIVI. 


f rQn.ha nrl 
1 1 cL| Udl 1U 


M 

IVI 


lUtJI Ull Itfb Wi HOI I 1 1 tJl^UtJI lL>y Udl 1U Odl 1 Utf UbfcJU Uy LI Ic VV 1 . I_UW Udl IU. O 1 OU OO^U 

MHz. High band: 5500-5700 MHz. (2 bits) 


UllcOl IIIUUc odp 


M 

IVI 


f\no hit that om idle 1 if \A/X cunnnrtc ni\/l 
wile Ull llldl Uqudlo I II VV I buppuilo UIVI. 


bUppUl I ICd 


IVI 


flnQ l^it Q/i i i^lc ^ if \A/T ci I i"*i"*/"M"f c i^/-*llin/-i 

vjut; uii iridi tjqudio i ii vv i buppurib puiniiy. 


ci innnct-f c q 
oUppUl I Ibd 


IVI 


f^lno hit that oniiQlc 1 if \A/T cin->i-»nrtc FQ/i 
wile Ull llldl UL|Udlb I II VV I bUppUllb ron. 


ho-cap 


M 


1 bit that indicates if WT is handover capable. 


cc-ho-cap 


IVI 


1 bit that indicates if WT is CC Handover capable. 


duty-cycle 


IVI 


percent of the MAC frame that the WT can use for uplink transmission (3 bits) 


cyclic-prefix 


iv/i 
IVI 


1 bit to indicate the type of the preamble used by this H/2-HD. 


time-gap-ach-uplink 


Kyi 
IVI 


Indicates time the respective H/2-HD needs after FCCH reception until it can 
receive again (3 bits) 


arq-delay-rx 


M 


ARQ delay of the receiver inside the respective H/2-HD (2 bits) 


arq-delay-tx 


M 


ARQ delay of the transmitter inside the respective H/2-HD (2 bits) 


auth-encr-selected 


M 


This parameter consists of an auth-info field and an encr-info field, which are 4 bits 
long each and define the type of auth. and encr. selected. 


dil-power-control 


M 


2 bits to indicate the type of DiL power control 


tx-arq-win-size 


M 


3 bits for window size 


rx-arq-win-size 


M 


3 bits for window size 


length-of-measurement 


M 


Indicates how many MAC frames the WT will still be absent for DFS. Reference 
frame is the frame in which this parameter is transmitted during CC Handover. A 
start-of-measurement parameter is not necessary, since the length-of-measurement 
field should be filled (in case of CC Handover) with the remaining absence time of 
the WT and since a start-of-measurement value in the future would not be possible, 
because the RLC is stopped during CC Handover. Afterwards, the new CC is 
responsible for polling the WT that is not aware of the CC Responsibility Handover 
due to its absence for DFS. The field is 6 bits long, 
length-of-measurement is set to if the WT is not absent for DFS. 


sleep-interval 


M 


Indicates how many MAC frames the WT will still be sleeping. Reference frame is 
the frame in which this parameter is transmitted during CC Handover. A fc-start- 
pointer parameter is not necessary, since the sleep-interval field should be filled (in 
case of CC Handover) with the remaining sleeping time of the WT and since a fc- 
start-pointer value in the future would not be possible, because the RLC is stopped 
during CC Handover. Afterwards, the new CC is responsible for polling the WT that 
is not aware of the CC Responsibility Handover, because it has been in sleeping 
mode during the procedure. Sleep time is 2 A 2 A sleep-interval (8 Bit), 
sleeping-interval is set to if the WT is not in sleeping mode. 


cl-common-attr-length 


M 


5 bits to indicate the length of the cl-common-attr container. 


cl-common-attr 


M 


This field represents a container in which CL related information is transferred that 
is common to all DUCs of the respective H/2-HD. The length M of the container can 
vary between and 31 octets in multiples of one octet. 


nr-mc-groups 


M 


Indicates the number L of DM multicast groups the H/2-HD is participating in and at 
the same time the number of group-mac-id fields that follow. The nr-mc-groups field 
is 5 bits long. 


first-group-mac-id 


M 


Multicast Group MAC ID of the first group the H/2-HD is member of. (8 bits) 


second-group-mac-id 


M 


Multicast Group MAC ID of the second group the H/2-HD is member of. (8 bits) 


(until L th -group-mac-id) 


M 
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For operation in a single HEE subnet MT-AUTH-ID is not absolutely necessary. Inside the subnet the MAC ID is 
already a unique identifier of the H/2-HD. This is why the transfer of the parameters mt-auth-id-type and mt-auth-id is 
only optional. The flag auth-id-pr, which indicates the presence of the MT AUTH ID during transmission, is 
nevertheless mandatory. 

NOTE: The information regarding DiL multicast groups is implicitly contained in this set of H/2-HD-specific 
parameters. 

The ASN.l tables of the parameters can be found in TS 101 761-2 [2], except for mit-id-pr, auth-id-pr, nr-cl-vid, cl- 
common-attr-length, nr-mc-groups, first-group-mac -id and second-group-mac -id, etc. The mt-id-pr, auth-id-pr, nr-cl-vid 
and the nr-mc-groups parameters are new and have the length and purpose described above. The group-mac -id fields are 
parameters, only transmitted during CC Handover, but are of the same type as mac -id. The cl-common-attr-length is also 
a new field which has the same type as the cl-conn-attr-length in TS 101 761-2 [2]. 

Beside the H/2-HD specific data, the data regarding the DiL connections of each H/2-HD has to be transmitted in 
addition. These parameters are treated in the following subclause. 

6.8.2.2 Parameters related to all maintained DiL connections 

Parameters related to DiL unicast connections on the one hand side and parameters related to DiL multicast connections 
on the other hand can be treated in a very similar way. Table 29 shows the parameters that shall be transmitted for each 
DiL unicast or multicast connection. 



Table 29: Parameters related to all maintained DM connections 



Parameter 


O/M 


Description 


first-mac-id 


M 


In case of a DiL unicast connection first-mac-id (8 bits) is filled with the mac-id of 
one of the two H/2-HDs involved in the connection. In case of a DiL multicast 
connection the first-mac-id field is filled with the mac-id of the sending H/2-HD. 


second-mac-id 


M 


In case of a DiL unicast connection second-mac-id (8 bits) is filled with the mac-id of 
the other of the two H/2-HDs involved in the connection. In case of a DiL multicast 
connection the second-mac-id field is filled with the mac-id of the multicast group for 
which the connection is maintained. 


cl-vid 


M 


This parameter consists of a cl-id field (8 bits) and a cl-version field (8 bits), which 
define the id and version of one of the multiple CLs. For every CL present within the 
H/2-HD the cl-vid parameter is transmitted. 


dlcc-id 


M 


Connection Identifier (6 bits). In case of a multicast connection the dlcc-id is always 
set to the value 63. 


direction 


M 


2 bits to indicate in case of a unicast connection one of the following four 
possibilities: simplex-forward, simplex-backward, duplex, duplex-symmetric. 
In case of multicast the connection is always of type simplex-forward. 


cl-conn-attr-length 


M 


Length of the cl-conn-attr(ibutes). Not all cl-attributes containers of all connections 
have the same length. Field is 5 bits long. 


cl-conn-attr 


M 


Container for CL specific information of the respective connection. The length of the 
container can vary between and 31 octets in multiples of one octet. 


forward-descr 


M 


Forward descriptor of the connection (56 bits in total). It comprises the following 
fields: allocation-type, cyclic prefix, ec-mode, arq-used, fee-used, arq-data, fee and 
fca-descr. 


backward-descr 


M 


Backward descriptor of the connection (56 bits in total). It comprises the same fields 
as the forward-descr (see above). In case of a multicast connection no backward- 
descr is present, which is indicated by the direction field being set to "simplex- 
forward". 



The ASN.l tables of the parameters can be found in TS 101 761-2 [2]. First-mac-id and second-mac -id are of the same 
type as peer-mac -id in TS 101 761-2 [2]. 

6.8.3 Data Transfer Procedure 

The parameters related to all associated H/2-HDs and the parameters related to all DiL connections are transmitted as 
byte string from the CC to the CC -candidate. The structure of this byte string and the coding of the parameters inside the 
byte string are defined in subclause 7.8. The byte string is transmitted as payload of one or several DiL DCCH LCHs 
called RLC_TRANS_CC_DATA PDUs. The coding of a RLC_TRANS_CC_DATA PDU is also defined in 
subclause 7.8. 
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If the byte string has to be transmitted on several RLC_TRANS_CC_DATA PDUs, it has to be segmented. The 
complete byte string shall be reassembled in the receiver. To reassemble the payload of the RLC_TRANS_CC_DATA 
PDUs in the correct order, each PDU shall have a Sequence Number (SN). For this purpose the SN-field defined in [1] 
shall be used. This is possible because the field is in general not used in case of a DiL DCCH. 

To ensure the integrity of the transmitted data, a "Go-back-n" ARQ mechanism shall be applied on the 
RLC_TRANS_CC_DATA PDUs using RLC_TRANS_CC_DATA_ACK PDUs. The sender window is implicitly 
defined by the size of the SN-field (1 024 PDUs). 

NOTE 1: It is implementation specific and e.g. load dependent, how many RLC_TRANS_CC_DATA_PDUs are 

transmitted before the sender (CC) waits for a RLC_TRANS_CC_DATA_ACK sent by the receiver (CC- 
candidate). 

With a RLC_TRANS_CC_DATA_ACK PDU the receiver acknowledges all PDUs up to an indicated SN-1. A 
ReceiveReady-flag (RR-flagj inside the RLC_TRANS_CC_DATA_ACK indicates whether further PDUs (starting with 
SN) have not been correctly received (RR-flag=0) or whether all PDUs up to (and including) SN have been correctly 
received (RR-flag=l). In the first case the sender (CC) shall re-send all PDUs beginning with the indicated SN. 

NOTE 2: In the second case the acknowledged SN may be lower than the SN of the last sent PDU. This may occur 
if the receiver (CC -candidate) has not yet processed the remaining PDUs. Nevertheless, the sender (CC) 
shall continue transmission of RLC_TRANS_CC_DATA PDUs beginning with SN where he had 
previously stopped transmission. 

If the sender (CC) has not received a RLC_TRANS_CC_DATA_ACK PDU within time T_trans_cc_data_cc, it shall 
re-send all RLC_TRANS_CC_DATA PDUs from the last acknowledged SN on. The receiver (CC -candidate) shall send 
at least one RLC_TRANS_CC_DATA_ACK PDU per frame (if there are RLC_TRANS_CC_DATA PDUs that have 
not yet been acknowledged). 

The timer T_trans_cc_data_cc shall be set to 6 ms. 

6.9 Authentication Key Management 

During association, the authentication phase is performed by a challenge/response technique in which each end-entity 
(CC and WT) uses a common secret authentication key auth-key to respond to the challenge sent by the other entity. 
Therefore, auth-key shall be downloaded into each H2-HD. Support for Authentication Key Distribution is mandatory 
for all H/2-HDs. 

Before a H/2-HD can take part in normal operation, meaning to start the CC selection process as a CC -capable device, 
or to start the association process as a basic WT, it shall first be initialized with the common secret authentication key 
and the owner identifier NET-ID of the home network, auth-key and NET-ID shall only be generated by the first CC- 
capable device to be installed in the home network and shall then be distributed to each new device to be installed. The 
NET-ID is broadcast by the CC in the BCCH and therefore known to every WT to be installed. The new WT shall store 
the NET-ID locally.. The authentication key auth-key is distributed in a secure way to avoid: 

• The key to be discovered by an eavesdropper; 

• The registration of an attacker's devices on a network. 

To avoid the registration of attacker's devices on a home network, each network shall be protected by a up to 23 octets 
PIN (Personal Identification Number). This PIN shall be stored in the CC (or each CC-capable device). When installing 
a new device, the user shall be asked via an implementation specific user interface whether: 

1) The device is the first device to be installed in the network; 

2) The device is a new additional device in the network (in that case, another device shall already have been 
installed in the network). 

In the first case, the CC capable device to be installed shall act as a CC without performing CC Selection, and shall 
generate the secret auth-key and the owner identifier NET-ID. In the second case, the new device to be installed shall act 
as a WT without performing CC Selection; the existing CC broadcasts NET-ID and shall send auth-key to this new 
device. 
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The PIN is CC-defined and a way of recovery may exist in case the PIN is lost. This way may be different for each 
manufacturer and is out of the scope of the present document. Moreover, a user may have the ability to change his PIN. 



Using an implementation specific interface, the user shall be asked if the device to be installed shall be the first 
operational device of a network. The first device of a network shall be CC-capable. To avoid wrong setting by the user, 
the device may indicate to the user if it has detected other CCs with or without displaying the associated NET-IDs. If the 
user set the device as the first device in the network, the device shall act as the CC on a free frequency and shall generate 
the secret key auth-key and the owner identifier NET-ID. Before generating them, the CC inquire the network's PIN 
from the user. If the PIN is validated by the CC, the CC generates auth-key and NET-ID. 

auth-key shall be the output of a random generator, or the result of a function /that depends on several parameters such 
as the device identifier, the network PIN and so on: 



The function /shall ensure the approximate uniqueness of auth-key. This means that given two different possible inputs 
of / the probability of obtaining the same key auth-key shall be less than 2~ 4( . However, /may be different for each 
manufacturer and its definition is out of the scope of the present document. 

NET-ID shall be a random number between and 959. During the installation and normal operation, the NET-ID shall 
be sent on BCCH by the acting CC. 

The user shall be able to undo or renew this first device installation process whenever he/she wants. 

NOTE: The manufacturer should make clear in the user manual that the user should not configure a new CC- 
capable device as the first one, if there is already one installed. 



If multiple CC-capable devices are configured by the user as the first devices of a network. It is very likely 
that they generate independent networks with different owner identifiers and authentication keys. 

By looking at an implementation specific indicator on each CC-capable device, the user should be able to 
detect if more than one CC is active at a time. If the user wants to have one single networks, he/she should 
undo the installation process of all CCs, except the one that he/she wants to keep. 



The generated authentication key auth-key shall be downloaded into each new device before it can use the network. This 
download phase involves the participation of the CC and the new H2-HD, and is composed of the following steps: 

1) Via an implementation specific user interface, the user shall activate the installation phase on the CC to install 
a new device; 

2) The CC shall inquire the network PIN from the user. If the entered PIN is validated by the CC, the download 
process is started and remains valid during a time window; The user may determine the duration of the time 
window; 

3) The user shall activate the installation phase on the new H2-HD to be installed. This device shall associate 
with the CC, requesting unicast encryption but no authentication. At the end of this association phase, the H2- 
HD and the CC agree on an encryption algorithm A (A may be DES or 3DES) and execute a Diffie-Hellman 
key exchange. The result of this step is a secret session key SSK shared by the new device and the CC. This 
session key shall be used by the algorithm A negotiated in the previous step. Figure 30 gives an overview 
which parts of the association procedure are carried out for the installation purpose. 



6.9.1 



Installation of the First Device in the Network 



auth-key = f(device_id, PIN,...). 



6.9.2 



Installation of a New Device in the Network 
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Figure 30: Association procedure for installation purposes 

1) After association, the new device shall give its identification number mt-id-number to the CC. The length of 
identification number is limited to 47 octets. The definition of the identification number is out of scope of the 
present document; 

2) The CC shall display the information of the new device (identification number) to the user and ask for 
validation; 

3) If the user validates, auth-key and the network's PIN are sent to the new device, encrypted by the algorithm A 
using the key SSK. As the length of auth-key and the PIN are not prescribed, two length-fields are also 
included in the PDU. From the length of the length-fields follows that auth-key and the PIN can be up to 46 
bytes long in total. At receipt, the device stores K, together with the NET-ID received on BCCH, in a non- 
volatile memory and sends the acknowledgement SSK(MD5(K)) to the CC; 

4) The new device disassociates and starts a normal association requesting encryption and authentication. 

NOTE: In order that the user can validate the identification number mt-id-number, it is to be displayed on the new 
device and the CC in the same format to be agreed upon by manufacturers. 

These steps are illustrated in Figure 3 1 . 
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Figure 31 : Messages exchanged during the installation of a new device 
Table 30: RLC-AUTHENTICATION-KEY-REQUEST 



RLC-AUTHENTICATION-KEY-REQUEST-ARG::= SEQUENCE! 



rlc-pdu-type RLC-HE-LCH-PDU-TYPE, 
extension-type EXTENSION-TYPE, 
mt-id-number-length MT-ID-NUMBER-LENGTH, 
mt-id-number MT-ID-NUMBER } 
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Table 31 : RLC-AUTHENTICATION-KEY-REQUEST-ACK 



RLC-AUTHENTICATION-KEY-REQUEST-ACK-ARG::= SEQUENCE{ 
rlc-pdu-type RLC-HE-SCH-PDU-TYPE 
extension-type EXTENSION-TYPE, 

_J 



Table 32: RLC-AUTHENTICATION-KEY-TRANSFER 



RLC-AUTHENTICATION-KEY-TRANSFER-ARG::= SEQUENCE! 
rlc-pdu-type RLC-HE-LCH-PDU-TYPE, 
extension-type EXTENSION-TYPE, 
valid-key VALID-KEY, 

-- indicated whether the exchanged 

- key is valid or not 
auth-key-length AUTH-KEY-LENGTH, 
pin-code-length PIN-CODE-LENGTH, 
auth-key AUTH-KEY, 

pin-code PIN-CODE} 



Table 33: RLC-AUTHENTICATION-KEY-TRANSFER-ACK 



RLC-AUTHENTICATION-KEY-TRANSFER-ACK-ARG::= SEQUENCE{ 


rlc-pdu-type 


RLC-HE-SCH-PDU-TYPE, 


extension-type 


EXTENSION-TYPE, 


valid-key 


VALID-KEY, 


-- indicated whether the exchanged 




- key is valid or not 


md5-of-auth-key 


MD5-ON-KEY} 



To download the common authentication key and the owner identifier from the CC, the new device shall first run an 
association phase without the authentication procedure. It shall abort this association, as soon as it detects that the CC to 
be associated with is a Non HE-compliant Device. If more than one active HE-compliant CCs are detected, the new 
device to be installed shall try out the CC, whose download process has been started by the user. When the 
authentication key has been exchanged, the WT shall disassociate and run the association procedure with the 
authentication phase. 

NOTE: The installation phase activation mentioned in steps (1) and (3) depends on the manufacturers and is out 
the scope of the present document. Moreover, the choice of algorithm A in step (3) depends on the 
required security level. The standard does not impose any algorithm but recommend to use 3DES to reach 
a high level of security. 

Three new RLC messages are introduced, namely RLC_AUTHENTICATION_KEY_REQUEST, 
RLC_AUTHENTICATION_KEY_TRANSFER, RLC_AUTHENTICATION_KEY_TRANSFER_ACK. The encoding 
of these RLC PDUs is defined in subclause 7.9. 

Once a H2-HD is installed, it can be reinstalled in any new network by repeating the eight operations mentioned above 
on the new network. In that case, the old authentication key may be deleted and replaced by the new one, if the 
manufacturer only supports one usage profile. Using an implementation specific user interface, the user may be enabled 
to select different usage profiles. Different usage profiles may correspond to different independent networks in the same 
or different places. In this case, for each usage profile a specific authentication key and owner identifier can be 
downloaded and stored in the H/2-HD. 
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7 RLC Protocol Data Units 
7.1 General 

The general concept of the transfer syntax of RLC is described in TS 101 761-1 [1] and TS 101 761-2 [2]. The specific 
transfer syntax formats for DiL RLC messages using SCH or LCH are defined below: 



Table 34: Transfer syntax format of the RLC SCH in Direct Link 





8 | 7 | 6 j 5 


4 j 3 [ 2 J 1 


Octet 1 


Defined in DLC TS 


Future Use 


Octet 2 


MSB RLC SCH PDU type 


Octet 3 


MSB EXTENSION-TYPE | MSB RLC DATA 


Octet 4 


MSB RLC DATA 




Octet 7 



Table 35: Transfer syntax format of the RLC LCH in Direct Link 





8 I 7 


6 | 5 | 4 | 3 | 2 | 1 


Octet 1 


Defined in DLC TS 


MSB Sequence number 


Octet 2 


Sequence number | MSB EXTENSION-TYPE 




Octet 3 


MSB RLC LCH PDU type 


_ 


Octet 4 


MSB RLC DATA 






Octet 51 



The definition of MSB for coding of RLC messages and its usage rules are given in TS 101 761-2 [2] (subclause 4.4). 

Table 36 lists all RLC messages defined in TS 101 761-2 [2] with changed requirement for support, i.e. the 
implementation changes from optional to mandatory. 



Table 36: RLC messages with changed requirement for support 



RLC MESSAGE 


CC-capable 


basic 




WT 


WT 




O/M 


O/M 


RLC DM COMMON KEY DISTR (/ACK) 


M 


M 


RLC INFO (-/ACK) 


M 


M 


RLC GROUP JOIN (/ACK/NACK) 


M 


O 


RLC GROUP LEAVE (/ACK/NACK) 


M 


O 


RLC DM SETUP 


M 


M 


RLC DM CONNECT (-/ACK/COMPLETE) 


M 


M 


RLC DM RELEASE (-/ACK) 


M 


M 


RLC DM RESET (-/ACK) 


M 


M 



Table 37 lists all parameters added or changed indicating whether the support is mandatory or optional. 



Table 37: Parameters added/changed 



Parameter 


O/M 


Description 


dm-attributes 


M 


Additional parameters needed for the DM are transferred as DM-Attributes. 
This parameter is for future use. 
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7.2 Terminal association for multiple convergence layers 

The terminal association consists of the MAC_Id assignment, the link capability, the encryption startup, the 
authentication and the information transfer procedure. Only the RLC PDUs for link capability exchange and the 
information transfer carry information which is needed for the multiple convergence layers association. For the 
corresponding message formats, parameters and their values please refer to subclause 6.2. 

For each convergence layer negotiated by WT and CC an RLC information transfer takes place. During this information 
transfer a parameter cl_data is exchanged between the corresponding CLs which is transparent to the RLC. The cl_data 
contains specific information needed for the coordination of the CLs. 

7.3 Link Adaptation in Direct Link Phase 

No new HE PDUs are defined for link adaptation in DiL. 

7.4 Power Control in Direct Link Phase 

RLC DM POWER CONTROL 

The transfer syntax table of RLC_DM_POWER_CONTROL message is shown below: 



Table 38: Transfer Syntax of RLC_DM_POWER_CONTROL 





8 7 6 


5 


4 | 3 | 2 | 1 


Octet 3 




dm -due- type 




Octet 4 




future use 


Octet 5 




Octet 6 




not used 


Octet 7 





Semantics: 



Parameter 


O/M 


Description 


dm-duc-type 


M 


Indicates whether DiL PC message concerns: 

0: unicast traffic from peer WT 

1 : multicast/broadcast traffic from peer WT 


adjust-tx 


M 


Recommended adjustment of transmit power level at peer WT 


wt-tx-level 


M 


Actual transmit power level of Sender 



dm-duc-type field indicates whether the RLC_DM_POWER_CONTROL message concerns unicast or 
multicast/broadcast traffic from the peer WT. 

During connectivity check, the field adjust_tx in RLC_DM_POWER_CONTROL message is set to 0000, which 
indicates that the WT was not able to make a recommendation for the transmit power level, since it has not been able to 
perform any measurements of reception quality. 

The mapping of the field adjust-tx, using 4 bits and a step size of 3dB, is shown in Table 40. 

The mapping of wt_tx_level, using 4 bits and a step size of 3dB, is shown in Table 39. This is the same mapping and 
accuracy as for the CC transmission power AP_Tx_Level [3]. 

Table 39 shows the mapping of the field adjust-tx, using 4 bits and a step size of 3dB. 
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Table 39: Mapping of adjust-tx field 



adjust-tx 


Adjust power level by: 


0000 


No change / 
Not enough measurements 


0001 


-3dB 


0010 


-6dB 






0111 


-21 dB 


1000 


Not used 


1001 


+ 3dB 


1010 


+ 6dB 






1111 


+ 21 dB 



Table 40 shows the mapping of wt-tx-level, using 4 bits and a step size of 3dB. 



Table 40: Mapping of wt-tx-level field 



wt-tx-level 


Mean EIRP [dBm] 


Accuracy [dB] 


1111 


30 


+/-4 


1110 


27 


+/-4 


1101 


24 


+/-4 


1100 


21 


+/-4 


1011 


18 


+/-4 


1010 


15 


+/-5 


1001 


12 


+/-5 


1000 


9 


+/-5 


0111 


6 


+/-6 


0110 


3 


+/-6 


0101 





+/-6 


0100 


-3 


+/-6 


0011 


-6 


+/-6 


0010 


-9 


+/-6 


0001 


-12 


+/-8 


0000 


-15 


+/-8 
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7.5 Link Quality Calibration for DM operation 

RLC CALIBRATION MEASUREMENT TRIGGER 

The transfer syntax table of RLC_CALIBRATION_MEASUREMENT_TRIGGER message is shown below: 



Table 41 : Transfer Syntax of RLC_CALIBRATION_MEASUREMENT_TRIGGER 





8 | 7 j 6 


5 j 4 


3 j 2 | 1 


Octet 3 




trigger-type 


future use 


Octet 4 


mac-id-1 (presence depending on trigger-type) 


Octet 5 


mac-id-2 (presence depending on trigger-type) 


Octet 6 


mac-id-3 (presence depending on trigger-type) 


Octet 7 


, not used 



Semantics: 



Parameter 


O/M 


Description 


trigger-type 


M 


2 bits that indicate if one, two, three or all WTs are triggered: 

00 -» All WTs are triggered (no MAC-ID included) 

01 -> One WT is triggered 

1 -> Two WTs are triggered 

1 1 -> Three WTs are triggered 


mac-ids 


M 


MAC-ID of triggered WTs (up to 3), in case of selective calibrations. 



RLC CALIBRATION MEASUREMENT 

The transfer syntax table of RLC_CALIBRATION_MEASUREMENT message is shown below (no parameters are 
contained): 

Table 42: Transfer Syntax of RLC_CALIBRATION_MEASUREMENT 





8 i 7 ! 6 


5 j 4 j 3 j 2 | 1 


Octet 3 




Not used 


Octet 4 




Octet 5 


Octet 6 


Octet 7 





Semantics: 



Parameter 


O/M 


Description 






No parameters included 



RLC CALIBRATION REPORT TRIGGER 

The transfer syntax table of RLC_CALIBRATION_REPORT_TRIGGER message is shown below: 



Table 43: Transfer Syntax of RLC_CALIBRATION_REPORT_TRIGGER 





8 j 7 j 6 


5 j 4 


3 j 2 j 1 


Octet 3 




trigger-type 


future use 


Octet 4 


mac-id-1 (presence depending on trigger-type) 


Octet 5 


mac-id-2 (presence depending on trigger-type) 


Octet 6 
Octet 7 


mac-id-3 (presence depending on trigger-type) 
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Semantics: 



Parameter 


O/M 


Description 


trigger-type 


M 


2 bits that indicate if one, two, three or all WTs are triggered to report: 

00 -> Report from all WTs 

01 -> Report from one WT 

10 -> Report from two WTs 

1 1 -> Report from three WTs 


mac-ids 


M 


MAC-IDs of up to 3 WTs (8 bits each), in case of selective reports 



RLC SHORT CALIBRATION REPORT 

The transfer syntax table of RLC_CALIBRATION_REPORT message in SCH: 

Table 44: Transfer Syntax of RLC_SHORT_CALIBRATION_REPORT 





8 7 6 


5 


4 3 2 1 


Octet 3 




rep-buf-status 


future use 


Octet 4 


mac-id-1 


Octet 5 


rss2-of-wt-1 | future use 


Octet 6 


mac-id-2 


Octet 7 


rss2-of-wt-2 j future use 



RLC CALIBRATION REPORT 

The transfer syntax table of RLC_CALIBRATION_REPORT message in LCH: 



Table 45: Transfer Syntax of RLC_CALIBRATION_REPORT 





8 


7 j 6 j 


5 I 4 


3 


2 j 1 


Octet 4 


number-of-reports 


rep-buf-status 


future use 


Octet 5 


mac-id-1 


Octet 6 




Octet 7 






mac-id-2 






Octet 8 




rss2-of-wt-2 








Octet 9 






mac-id-3 






Octet 1 




rss2-of-wt-3 








Octet 1 1 






mac-id-4 






Octet 12 




rss2-of-wt-4 








Octet- 


etc for other wts 


Octet ... 












Octet ... 






not used 






Octet 51 













Semantics: 



Parameter 


O/M 


Description 


rep-buf-status 


M 


Indicates whether reports still need to be broadcast. 

All reports have been transmitted 

1 Still reports in buffer 


cap-report-list 


M 


Each report contains a MAC-ID (8 bits) and the corresponding RSS2 
value (6 bits) of the WT. 



RLC CALIBRATION LINKQUALITYMAP REQUEST 

The transfer syntax table of RLC_CALIBRATION_LINKQUALITYMAP_REQUEST message: 
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Table 46: Transfer Syntax of RLC_CALIBRATION_LINKQUALITYMAP_REQUEST 





8 I 7 i 6 


5 


4 I 3 i 2 j 1 


Octet 3 




request- type 


future use 


Octet 4 


mac-id 


Octet 5 


not used 


Octet 6 


Octet 7 



Semantics: 



Parameter 


O/M 


Description 


request-type 


M 


Indicates whether the whole map is requested or only information related 
to one WT with mac-id. 

Whole Map request 

1 Only RSS2 information related to the MAC-ID given below 


mac-id 


M 


mac-id of the specific WT in case of request-type=1 . With request-type=0 
the field is not present. 



RLC CALIBRATION LINKQUALITYMAP 

The transfer syntax table of RLC_CALIBRATION_LINKQUALITYMAP message: 



Table 47: Transfer Syntax of RLC_CALIBRATION_LINKQUALITYMAP 





8 I 7 i 6 | 5 


4 


3 j 2 | 1 


Octet 4 


number-of-mac-ids 


map-ext-ind 


future use 


Octet 5 


mac-id-of-sender-wt-i 


Octet 6 


no-of-reports-wt-i 


Octet 7 


mac-id-receiver-wt-ix 


Octet 8 


age-of-rss2 j rss2-for-wt-ix 


Octet 9 


mac-id-receiver-wt-iy 




age-of-rss2 I rss2-for-wt-iy 


Octet 6+(2*N) 




Octet 7+(2*N) 


mac-id-of-sender-wt-j 


Octet 8+(2*N) 


no-of-reports-wt-j 


Octet 9+(2*N) 


mac-id-wt-jx 


Octet 10+(2*N) 


age-of-rss2 j rss2-for-wt-jx 


Octet 1 1 +(2*N) 


mac-id-wt-jy 


Octet 12+(2*N) 


age-of-rss2 j rss2 -for-wt-jy 






8+(2*N)+(2*K) 




9+(2*N)+(2*K) 




Octet 51 
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Semantics: 



Parameter 


O/M 


Description 


number-of-mac-ids 


M 


Number of the MAC-IDs of the WT_xi, whose transmitted RSS2 values 
are being reported by WT_i. 


map-ext-ind 


M 


extension indication bit whether more 
RLC_CALIBRATION_LINKQUALITYMAP PDUs follow 


complete-report-list 


M 


Contains following Reports from each WT_i, whose RSS2 values have 
been measured by other WT_ix: 
MAC-ID ofWT_i(8 Bits) 

Number of reports for measurement PDU from WT_i (8 Bits) 
Report list (N * 16 Bits): 
MAC-ID of WT_ix (8 Bits) 

RSS2 measured by WT_ix when signal transmitted by WT_i (6 Bits) 
Age (2 bits) indicates the time since the measurement was performed: 
00: within last 100 msec 
01 : within last 250 msec 
10: within last 500 msec 
1 1 : older than 1 sec 

In case of a partial quality map only the reports concerning one reporting 
WT i are included in the PDU. 



If RLC_CALIBRATION_LINKQUALITYMAP contains a partial map, dedicated to one WT_i only, it is transmitted on 
DL DCCH, if it contains a complete quality map or a part of the complete quality map it is transmitted on DL RBCH. 

NOTE: The complete quality map may not fit into one LCH, in which case several 

RLC_CALIBRATION_LINKQUALITYMAP PDUs will be broadcast by the CC. number-of-mac-ids 
only indicates the number of WT_i in the current PDU, whose RSS2 values have been measured by other 
WT_ix. 

7.6 DLC User Connection Control 
7.6.1 Fixed slot allocation for DM 

Void. 
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7.6.2 Multicast in DiL phase 

The transfer syntax tables below display the structures of all messages used for Direct Link Multicast Connection Setup, 
Modify and Release. 

7.6.2.1 RLC-DM-MC-SETUP encoding 





8 | 7 


6 


5 


4 


3 


2 | 1 


Octet 4 


PEER-MAC-ID 


Octet 5 


SOURCE-MAC-ID 


Octet 6 


CL-ID 


Octet 7 


EXT-IND | 


CL-ATTRIBUTE-LENGTH(L) 




# of DUC:s 


Octet 8 


#of DUC:s(N) 


Future use 


Octet 9 


DUC1- 


DLCC-ID 


Octet 1 


MIN-REQ-RECEIVERS 




CL-CONN ATTR 


Octet Y 


DUC1 -FW-TYPE-OF- 


Future 


cyclic- 


FEC- 


EC-MODE 




ALLOCATION 




use 


prefix 


USED 




Octet... 


DUC1-FW-NUM-OF-RETRANSMISSIONS 


Future 


DUC1-FW-ARQ-WIN-SIZE 




FEC-FW 


Future Use 


Octet... 


PER-#-MAC-FRAME(SCH) 


PER-#-MAC-FRAME(LCH) 


Octet... 


REQ | PHY-MODE-SCH 


PHY-MODE-LCH 


Octet... 


REQUESTED-NUM-OF-LCH 


Octet... 


MINIMUM-NUM-OF-LCH 


Octet X 


DUC1 -BW-TYPE-OF- 


Future 


cyclic- 


FEC- 


EC-MODE 




ALLOCATION 




use 


prefix 


USED 




Octet... 


DUC1-BW-NUM-OF-RETRANSMISSIONS 


Future 


DUC1-BW-ARQ-WIN-SIZE 




FEC-BW 


Future Use 


Octet... 


PER-#-MAC-FRAME(SCH) 


PER-#-MAC-FRAME(LCH) 


Octet... 


REQ | PHY-MODE-SCH 


PHY-MODE-LCH 


Octet... 


REQUESTED-NUM-OF-LCH 


Octet... 


MINIMUM-NUM-OF-LCH 


Octet ... 


CL-COMMON-ATTR-LENGTH 


Octet ... 














Octet ... 






CL-COMMON-ATTR 






Octet ... 














Octet ... 














Octet ... 






Not used 






Octet 51 















Y=10+L 

X=10+L+6 if asymmetric duplex with FCA and ARQ or FEC 

Semantics of parameters specifically introduced for the DiL multicast case: 
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Parameter 


O/M 


Description 


source-mac-id 


M 


identifies the multicast sender 


min-req-receivers 


M 


number of receivers required to establish the multicast connection 


cl-common-attr 


M 


common attributes concerning CL 


cl-common-attr-length 


M 


giving the length of the cl-common-attr field, can be set to zero. 



7.6.2.2 RLC-DM-MC-CONNECT encoding 





8 I 7 


6 


5 


4 


3 


2 I 1 


Octet 4 


PEER-MAC-ID 


Octet 5 


SOURCE-MAC-ID 


Octet 6 


CL-ID 


Octet 7 


Future use | 


CL-ATTRIBUTE-LENGTH(L) 




#of DUC:s 


Octet 8 


#of DUC:s(N) 


Future use 


Octet 9 


DUC1- DIRECTION 


DLCC-ID 








CL-CONN ATTR 




















Octet Y 


DUC1 -FW-TYPE-OF-ALLOCATION 


Future use 


Cyclic- 


FEC-USED 


EC-MODE 


Octet... 


DUC1 -FW-NUM-OF-RETRANSMISSIONS 


Future use 


DUC1 


FW-ARQ-WIN-SIZE 




FEC-FW 


Future Use 


Octet- 


PER-#-MAC-FRAME(SCH) 


PER-#-MAC-FRAME(LCH) 


Octet... 


reqsch | PHY-MODE-SCH 


PHY-MODE-LCH 


Octet... 


REQUESTED-NUM-OF-LCH 


Octet- 


MINUMUM-NUM-OF-LCH 


Octet X 


DUC1 -BW-TYPE-OF-ALLOCATION 


Future use 


cyclic- 
prefix 


FEC-USED 


EC-MODE 


Octet- 


DUC1 -BW-NUM-OF-RETRANSMISSIONS 


Future use 


DUC1 


BW-ARQ-WIN-SIZE 




FEC-BW 


Future Use 


Octet... 


PER-#-MAC-FRAME(SCH) 


PER-#-MAC-FRAME(LCH) 


Octet... 


reqsch | PHY-MODE-SCH 


PHY-MODE-LCH 


Octet- 


REQUESTED-NUM-OF-LCH 


Octet... 


MINUMUM-NUM-OF-LCH 


Octet... 














Octet... 






Not used 






Octet 51 















Semantics of parameters specifically introduced for the DiL multicast case: 



Parameter 


O/M 


Description 


source-mac-id 


M 


identifies the multicast sender 
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7.6.2.3 RLC-DM-MC-CONNECT-ACK encoding 





8 I 7 


6 | 5 | 4 i 3 


I 2 | 1 


Octet 4 


PEER-MAC-ID 


Ortpt 5 


SOURCE-MAC-ID 


Ortpt 6 


CL-ID 


Octet 7 


Future use | 


CL-CONN-ATTR-LENGTH (L) 


| # of DLCC:s+CL-ATTR 


Octet 8 


# of DLCCs (N) 




Octet 9 


Future use 


DLCC-ID-1 


Octet ... 




CL-CONN-ATTR-1 




Octet ... 




DLCC-ID-N 




Octet ... 




CL-CONN-ATTR -N 




Octet 
8+L*N 








Octet ... 








Octet ... 




Not used 




Octet 51 









Semantics of parameters specifically introduced for the DiL multicast case: 



Parameter 


O/M 


Description 


source-mac-id 


M 


identifies the multicast sender 



7.6.2.4 RLC-DM-MC-CONNECT-COMPLETE encoding 





8 I 7 


6 


I 5 | 4 | 3 | 2 | 


1 


Octet 4 


PEER-MAC-ID 


Octet 5 


SOURCE-MAC-ID 


Octet 6 


Future use 


! # of DLCC:s (N) 




Octet 7 


Future use 


DLCC-ID -1 


Octet ... 


Future use 




Octet 5+N 


Future use 


DLCC-ID -N 


Octet 6+N 










Octet ... 






Not used 




Octet 51 











Semantics of parameters specifically used for the DiL multicast case: 



Parameter 


O/M 


Description 


source-mac-id 


M 


identifies the multicast sender 



7.6.2.5 RLC-DM-MC-CONNECT-COMPLETE-ACK encoding 





8 ! 7 | 6 


5 | 4 | 3 | 2 | 1 


Octet 3 




Future use 


Octet 4 


[ PEER-MAC-ID 


Octet 5 


SOURCE-MAC-ID 


Octet 6 




Future use 


Octet 7 





Semantics of parameters specifically introduced for the DiL multicast case: 



Parameter 


O/M 


Description 


source-mac-id 


M 


identifies the multicast sender 
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7.6.2.6 RLC-DM-MC-MODIFY-REQ encoding 





8 | 7 


6 


5 


4 


3 


2 | 1 


Octet 4 


PEER-MAC-ID 


Octet 5 


SOURCE-MAC-ID 


Octet 6 


Future | 


CL-ATTRIBUTE-LENGTH(L) 




#of DUC:s 


Octet 7 


#of DUC:s(N) 


Future use 


Octet 8 


DUC1-DIRECTION 


DLCC-ID 








CL-CONN ATTR 




















uciei Y 


DUC1 -FW-TYPE-OF-ALLOCATION 


Future 


cyclic- 


FEC-USED 


EC-MODE 








use 


prefix 






uciei... 


DUC1-FW-NUM-OF-RETRANSMISSIONS 


Future 


DUC1-FW-ARQ-WIN-SIZE 




FEC-FW 


Future Use 


uctet... 


PER-#-MAC-FRAME(SCH) 


PER-#-MAC-FRAME(LCH) 


uctet... 


REQSCH | PHY-MODE-SCH 


PHY-MODE-LCH 


Octet... 


REQUESTED-NUM-OF-LCH 


uciei... 


MINUMUM-NUM-OF-LCH 


Octet X 


DUC1 -BW-TYPE-OF-ALLOCATION 


Future 


cyclic- 


FEC-USED 


EC-MODE 








use 


prefix 






Octet... 


DUC1-BW-NUM-OF-RETRANSMISSIONS 


Future 


DUC1-BW-ARQ-WIN-SIZE 




FEC-BW 


Future Use 


Octet... 


PER-#-MAC-FRAME(SCH) 


PER-#-MAC-FRAME(LCH) 


Octet- 


REQSCH | PHY-MODE-SCH 


PHY-MODE-LCH 


Octet... 


REQUESTED-NUM-OF-LCH 


Octet... 


MINUMUM-NUM-OF-LCH 


Octet... 














Octet... 






Not used 






Octet 51 















Semantics of parameters specifically introduced for the DiL multicast case: 



Parameter 


O/M 


Description 


source-mac-id 


M 


identifies the multicast sender 
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7.6.2.7 RLC-DM-MC-MODIFY encoding 





8 | 7 


6 


5 


4 


3 


2 | 1 


Octet 4 


PEER-MAC-ID 


Octet 5 


SOURCE-MAC-ID 


Octet 6 


Future ] 


CL-ATTRIBUTE-LENGTH(L) 




#of DUC:s 


Octet 7 


#of DUC:s(N) 


Future use 


Octet 8 


DUC1-DIRECTION 


DLCC-ID 


Octet 9 


repetition-counter 


Octet 1 


repetition-counter 






frame-count 








CL-CONN ATTR 




















uctet Y 


DUC1-FW-TYPE-OF-ALLOCATION 


Future 


cyclic- 


FEC-USED 


EC-MODE 


Octet... 


DUC1 -FW-NUM-OF-RETRANSMISSIONS 


Future 


DUC1-FW-ARQ-WIN-SIZE 




FEC-FW 


Future Use 


Octet... 


PER-#-MAC-FRAME(SCH) 


PER-#-MAC-FRAME(LCH) 


Octet... 


REQSCH | PHY-MODE-SCH 


PHY-MODE-LCH 


Octet... 


REQUESTED-NUM-OF-LCH 


Octet... 


MINUMUM-NUM-OF-LCH 


Octet X 


DUC1 -BW-TYPE-OF-ALLOCATION 


Future 
use 


cyclic- 
prefix 


FEC-USED 


EC-MODE 


Octet... 


DUC1-BW-NUM-OF-RETRANSMISSIONS 


Future 


DUC1-BW-ARQ-WIN-SIZE 




FEC-BW 


Future Use 


Octet... 


PER-#-MAC-FRAME(SCH) 


PER-#-MAC-FRAME(LCH) 


Octet... 


REQSCH | PHY-MODE-SCH 


PHY-MODE-LCH 


Octet... 


REQUESTED-NUM-OF-LCH 


Octet... 


MINUMUM-NUM-OF-LCH 


Octet... 














Octet... 






Not used 






Octet 51 















Semantics of parameters specifically introduced for the DiL multicast case: 



Parameter 


O/M 


Description 


source-mac-id 


M 


Identifies the multicast sender 


repetition-counter 


M 


repetition of the value frame-count in BCCH 


frame-count 


M 


The MAC frame number appearing in BCCH 



7.6.2.8 RLC-DM-MC-MODIFY-ACK encoding 





8 |7|6|5|4|3|2|1 


Octet 4 


PEER-MAC-ID 


Octet 5 


SOURCE-MAC-ID 


Octet 6 


CL-CONN-ATTR-LENGTH | # of DLCC:s+CL-CONN-ATTR 


Octet 7 


# of DLCCs | Future use 


Octet 8 


Future use DLCC-ID-1 


Octet ... 


CL-CONN-ATTR-1 




Future use DLCC-ID... 




CL-CONN-ATTR ... 








Not used 


Octet 51 





Semantics of parameters specifically introduced for the DiL multicast case: 



Parameter 


O/M 


Description 


source-mac -id 


M 


Identifies the multicast sender 
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7.6.2.9 RLC-DM-MC-RELEASE encoding 





8|7j6i5|4i3|2|1 


Octet 4 


PEER-MAC-ID 


Octet 5 


SOURCE-MAC-ID 


Octet 6 


CAUSE i # of DLCC:s 


Octet 7 


Future use 


DLCC-ID -1 


Octet 8 


Future use 




Octet ... 


Future use 


DLCC-ID N 


Octet ... 


Not used 


Octet... 


Octet 51 



Semantics of parameters specifically introduced for the DiL multicast case: 



Parameter 


O/M 


Description 


source-mac-id 


M 


identifies the multicast sender 



7.6.2.1 RLC-DM-MC-RELEASE-ACK encoding 





8!7|6l5!4l3|2!l 


Octet 4 


PEER-MAC-ID 


Octet 5 


SOURCEMAC-ID 


Octet 6 


Future use | # of DLCC:s 


Octet 7 


Future use 


DLCC-ID-1 


Octet 8 


Future use 




Octet ... 


Future use 


DLCC-ID-N 


Octet ... 


Not used 


Octet... 


Octet 51 



Semantics of parameters specifically introduced for the DiL multicast case: 



Parameter 


O/M 


Description 


source-mac-id 


M 


identifies the multicast sender 



7.7 Dynamic CC Selection 

In each CC Probing Frame a CC-capable device in the CC Selection Process transmits a Probing Beacon with the 
structure of the usual BCCH and the following content: 
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Table 48: Contents of the CC Probing BCCH 



Name 


Lengin idiis; 


CaltinM 

oeuing 


1 1 Cll 1 IC ^UUIILCI ^oUI al 1 IUI C 1 oCCUj 


4 


qc HpfinpH in hacir 1 Dl C 1 . 

do UCI II IdU III UClOlU IO 


NET-ID 


10 


0000000000 


AP-ID 


10 


nnnnnnnnnn 


Antpnnp ID 

ni ii id 1 1— • 


3 


000 


AP TX IpvpI 

/\ 1 1 /\ lUVCI 


4 


1111 


AP RX LJL IpvpI 


3 


000 


Pnintpr tn FCM 


12 


nnnnnnnnnnnn 


Lpncith FOH 

1— CI IUU 1 1 \w/ 1 1 


4 


0000 


PHY Mndp nf FOH 

in i iviuuc ui i 1 i 


2 




Pnintpr tn ROH 

1 \J 1 1 1 LCI LU 1 1WI 1 


13 


0000000000000 


1 pnnth nf RP,H 


\j 


nnnnn 


f-iiiprn 1 Qnapp hptwppn ROH 


2 


00 


DL RBCH indicator 


1 


o 


DST (Data to sleeping terminals) 


1 





Uplink preamble 


1 





Version indicator 


3 


000 


AP traffic load indicator 


3 


000 


Maximum power indicator 


1 


1 


# of antenna elements 


3 


000 


Future use 


14 


any 


CRC 


24 


as defined in 


Total length 


120 





The CC Probing BCCH is identified uniquely by 'Length of RCH' = 00000, which is not allowed in normal operation. 
All other fields shall be ignored on reception of a CC Probing BCCH. 

7.8 CC Responsibility Handover 

7.8.1 Encoding of CC Database Parameters for CC Handover 

The H/2-HD specific parameters shall be encoded as in Table 49. 
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Table 49: Transfer Syntax Table of H/2-HD Specific Parameters (Content-field of a H/2-HD-DATA- 

BLOCK) 



8 



1 



Octet 1 



mac-id 



Octet 2 



dlc-version-selected 



rlc-version-selected 



Octet 3 



Octet 4 



64-qam? | freq-band | (jrn-Cap | support-lea | support-tsa 



nr-cl-vid (N) 



Octet 5 



cl-id-1 



Octet 6 



cl-version-1 



Other CL-ID and CL-Version 



Octet 5+(2*N) 



ho-cap 



cc-ho-cap 



duty-cycle 



time-gap-ach-ul 



Octet 6+(2*N) 



arq-delay-rx 



arq-delay-tx 



auth-selected 



Octet 7+(2*N) 



encr-selected 



cyclic prefix 



Octet 8+(2*N) 



Octet 9+(2*N) 



dil-power-control 



rx-arq-win-size 



Octet 10+(2*N) 



length-of-measurement-DFS 



Octet 11 +(2*N) 



sleep-interval 



cl-common-attr-length (M octets) 




cl-common-attr 



Octet 
11+(2*N)+M 



Oct.12+(2*N)+M 



nr-mc-groups (L) 



Future use 



mac-id-1 



Octet 
12+(2*N)+M+L 



other-mac-ids 



13+(2*N)+M+L 



auth-id-pr? | mt-auth-id-type 



future use 



mt-auth-id 



Octet 
19+(2*N)+M'+L 
or 

21+(2*N)+M+L 
or 

59+(2*N)+M+L 
or 

105+(2'N)+M+L 



Octet 1 



mac-id 



Octet 2 



dlc-version 



Octet 3 



Octet 5 



rlc-version 



cl-id-1 



nr-cl-vid (N) 



Octet 6 



cl-version-1 



Other CL-ID and CL-Version 



Octet 5+(2*N) 



64-qam? | dm-cap 



dm-use-key | polling? 



time-gap-ach-ul 




Octet 6+(2*N) 



arq-delay-rx 



arq-delay-tx 



Octet 7+(2*N) 



encr-selcted 



Octet 8+(2*N) 



dil-power-control 



rx-arq-win-size 



Octet 9+(2*N) 



length-ot-measurement-DFS 



Octet 10+(2*N) 



Octet 11 +(2*N) 



sleep-interval 



cl-common-attr-length (M octets) 



cl-common-attr 



Octet 
11+(2*N)+M 



Oct.12+(2*N)+M 



nr-mc-groups (L) 



Future use 



mac-id-1 



Octet 
12+(2*N)+M+L 



other-mac-ids 



13+(2*N)+M+L 



mt-id-pr? | auth-id-pr? | mt-auth-id-type 



mt-id 



Octet 
45+(2*N)+M 



mt-auth-id 



Octet 
51+(2*N)+M 
or 53+(2*N)+M 
or 92+(2*N)+M 
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The optional parameter mt-auth-id is transmitted at the end of the H/2-HD specific field. A flag auth-id-pr indicates 
whether MT-AUTH-ID is present or not. 

The total length of the H/2-HD specific field depends on the number N of CLs present within the H/2-HD (nr-cl-vid), 
the length M of the cl-common-attr field, the number of multicast groups L the H/2-HD is participating in (nr-mc- 
groups) as well as the presence and the type of the MT-AUTH-ID (auth-id-pr and mt-auth-id-type). The H/2-HD 
specific field may not fit into one PDU (always a maximum of 48 octets available). 

For this reason the transmission as byte string has been foreseen for the parameter transfer (see subclause 6.8.2). The 
transmitted byte string consists of data blocks. Two types of data blocks are distinguished: H/2-HD-DATA-BLOCK 
and CONN-DATA-BLOCK. A data block consists of a type-field, a length-field and a content-field. A H/2-HD- 
DATA-BLOCK contains the information relevant to one H/2-HD. The content-field follows the structure in Table 49 in 
case of a H/2-HD-DATA-BLOCK. The length-field is to indicate the variable length of the content-field which varies 
from 13 to 170 octets in case of a H/2-HD-DATA-BLOCK. The length-field is to indicate the variable length of the 
content-field in number of octets. The length-field has itself a length of 8 bits. The type-field is also 8 bits long. Only the 
last bit is to distinguish between the two types of data blocks (0 for H/2-HD-DATA-BLOCK, 1 for CONN-DATA- 
BLOCK), the other bits are for future use. Table 50 illustrates the structure of a data block. 



Table 50: General Structure of a Data Block 





8|7|6|5|4|3|2|1 


Octet 1 


type-field 


Octet 2 


lenqth-field 


Octet 3 


content-field 



The content-field of a CONN-DATA-BLOCK, which contains the parameters of one unicast or multicast DM 
connection, shall be encoded like shown in Table 5 1 . 

Table 51 : Transfer Syntax Table of DiL Connection Specific Parameters (Content-field of a CONN- 
DATA-BLOCK) 





8 | 7 | 6 | 5 


4 


3 | 2 | 1 


Octet 1 


first-mac-id 


Octet 2 


second-mac-id 


Octet 3 


cl-id 


Octet 4 


dlcc-id 




| direction 


Octet 5 


cl-conn-attr-length 




future use 


Octet 5+M 


cl-conn-attr 


Octet Y 


DUC-FW-TYPE-OF-ALLOCATION | Future use 


cyclic-prefix 


FEC-USED | ec-mode 


Octet... 


DUC-FW-NUM-OF-RETRANSMISSIONS 


Future use 


DUC-FW-ARQ-WIN-SIZE 




FEC-FW 


Future Use 


Octet... 


PER-#-MAC-FRAME(SCH) 


PER-#-MAC-FRAME(LCH) 


Octet... 


reqsch | PHY-MODE-SCH 


PHY-MODE-LCH 


Octet... 


REQUESTED-NUM-OF-LCH 


Octet... 


MINUMUM-NUM-OF-LCH 


Octet X 


DUC-BW-TYPE-OF-ALLOCATION | Future use 


cyclic-prefix 


FEC-USED ec-mode 


Octet... 


DUC-BW-NUM-OF-RETRANSMISSIONS 


Future use 


DUC-BW-ARQ-WIN-SIZE 




FEC-BW 


Future Use 


Octet... 


PER-#-MAC-FRAME(SCH) 


PER-#-MAC-FRAME(LCH) 


Octet... 


reqsch | PHY-MODE-SCH 


PHY-MODE-LCH 


Octet... 


REQUESTED-NUM-OF-LCH 


Octet... 


MINUMUM-NUM-OF-LCH 



The total length of the DiL connection specific field depends on many parameters like the length of the cl-common-attr 
field, the presence of the forward-descriptor respectively backward-descriptor, the fee-used bit (green octet may not 
be present) and the ec-mode (blue octets may not be present). The maximum length of the content-field can be 50 octets. 
The CONN-DATA-BLOCK follows the general structure of a data block in Table 50. 
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H/2-HD-DATA-BLOCKS and CONN-DATA-BLOCKS are concatenated to form the byte string that is transmitted as 
payload of the RLC_TRANS_CC_DATA PDUs. First the H/2-HD-DATA-BLOCKS of all HDs shall be transmitted 
followed by the CONN-DATA-BLOCKS of all DM connections. 

NOTE: A data block is segmented if its length exceeds the length of the payload field of an RLC LCH PDU (48 
octets). By concatenating all received payload fields within (the memory of) the receiver, automatic 
reassembling can be performed. 

7.8.2 Transfer Syntax Tables of CC Handover PDUs 

As shown in Table 52 no parameters are included in the RLC_CC_HO_REQUEST, RLC_CC_HO_REQUEST_ACK, 
RLC_CC_HO_NOTIFY, RLC_START_CC_ACK and RLC_CC_START_OPERATION. 





8 i 7 l 6 


5 | 4 | 3 | 2 | 1 


Octet 3 




Not used 


Octet 4 




Octet 5 


Octet 6 


Octet 7 



Table 52: RLC_CC_HO_REQUEST, RLC_CC_HO_REQUEST_ACK, RLC_CC_HO_NOTIFY, 
RLC_START_CC_ACK and RLC_CC_START_OPERATION encoding 



The RLC_TRANS_CC_DATA PDU is encoded like illustrated in Table 53. In the transfer syntax table the whole PDU 
is shown including parts defined in TS 101 761-1 [1] and TS 101 761-2 [2]. The reason is that the Sequence Number 
field defined in TS 101 761-1 [1] is used for the Go-Back-n ARQ mechanism (see subclause 6.8.3). During one CC 
Handover, the Sequence Number is incremented by 1 (modulo 1024) with each transmitted RLC_TRANS_CC_DATA 
PDU (and starting with 0). The purpose of the EXT-IND field is to indicate if the PDU is the last 
RLC_TRANS_CC_DATA PDU transmitted in this CC Handover. For all previous PDUs the field is set to 0. The byte 
string contains the H/2-HD-DATA-BLOCKs and CONN-DATA-BLOCKs the purpose and encoding of which has been 
explained in subclause 7.7.1. 





8 | 7 


6 ! 5 j 4 ! 3 j 2 j 1 


Octet 1 


Ich-pdu-type 


sequence-number 


Octet 2 


sequence-number j future use 


Octet 3 


rlc-pdu-type 


Octet 4 


ext-ind r future use 


Octet 5 


Byte-String (containing H/2-HD-DATA-BLOCKs and CONN-DATA-BLOCKs) 


Octet 6 


Octet... 


Octet- 


Octet... 


Octet ... 


Octet ... 


Octet 51 


Octet 52 


CRC-24 


Octet 53 


Octet 54 



Table 53: RLC_TRANS_CC_DATA encoding 
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A certain number of RLC_TRANS_CC_DATA PDUs is acknowledged by one RLC_TRANS_CC_DATA_ACK PDU 
by the receiver. The receiver shall send at least one RLC_TRANS_CC_DATA_ACK PDU per frame (if there are 
RLC_TRANS_CC_DATA PDUs that have not yet been acknowledged). The RLC_TRANS_CC_DATA_ACK PDU 
contains the Sequence number of the RLC_TRANS_CC_DATA PDU that is expected next (cf. Table 54). The error bit 
indicates whether the sender (CC) shall re-send RLC_TRANS_CC_DATA PDUs from the contained Sequence number 
on. In case the error bit has the value 0, the sender shall take no action. 



Table 54: RLC_TRANS_CC_DATA_ACK encoding 





8 | 7 | 6 


5 i 4 i 3 ! 2 ! 1 


Octet 3 






Octet 4 




Octet 5 


not used 


Octet 6 


Octet 7 



The RLC_START_CC PDU contains the start-mac -frame parameter which determines the start time for the new CC to 
take over CC responsibility (Table 55). 



Table 55: RLC_START_CC encoding 





8 j 7 j 6 


5 | 4 | 3 j 2 | 1 


Octet 3 






Octet 4 




Octet 5 




Octet 6 


not used 


Octet 7 





7.9 Authentication Key Management 

The transfer syntax table of the RLC_AUTHENTICATION_KEY_REQUEST is defined in Table 56. 



Table 56: RLC_AUTHENTICATION_KEY_REQUEST encoding 





8[7[6J5_)4i3 


2 | 1 


Octet 4 


mt-id-number-length 




Octet 5 


mt-id-number 


Octet 6 


Octet- 


Octet... j 


Octet- 


Octet ... 


not used 


Octet ... 


Octet 51 





Semantics: 



Parameter 


O/M 


Description 


MT-ID-NUMBER- 
LENGTH 


M 


6 bits to indicate the length of the MT-ID-NUMBER in number of octets. 


MT-ID-NUMBER 


M 


Some Identifier of the WT. 



No parameters are included in the RLC_AUTHENTICATION_KEY_REQUEST_ACK PDU (cf. Table 57). 
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8 ; 7 ; 6 


5 | 4 ; 3 j 2 | 1 


Octet 3 






Octet 4 
Octet 5 
Octet 6 
Octet 7 




Not used 



Table 57: RLC_AUTHENTICATION_KEY_REQUEST_ACK encoding 



Table 57 shows the encoding of the RLC_ AU THENTIC ATION_KE Y_TR AN S FER PDU. 





8 


7 i 6 | 5 i 4 ] 3 j 2 1 


Octet 4 


valid-key 


auth-key-length Future use 


Octet 5 


pin-code-length | future use 


Octet 6 


auth-key 


Octet... 


Octet... 


pin-code 


Octet... 


Octet ... 


not used 


Octet ... 


Octet 51 



Table 58: RLC_AUTHENTICATION_KEY_TRANSFER encoding 



Semantics: 



Parameter 


O/M 


Description 


VALID-KEY 


M 


1 bits that equals 1 if the key is valid. 


AUTH-KEY-LENGTH 


M 


Length of the AUTHENTICATION KEY in number of octets (6 bits). 


PIN-CODE-LENGTH 


M 


Length of the PIN code of the subnet in number of octets (6 bits). 


AUTH-KEY 


M 


Common AUTHENTICATION-KEY of the subnet. The length of the field can vary 
from to 46 octets. 


PIN-CODE 


M 


PIN code of the network in binary format, encoded with the Secret Session Key 
(SSK). The length of the field can vary from to 23 octets. 



PvLC_AUTHENTICATION_KEY_TRANFER_ACK is defined in Table 59. 





8 


7i6j5|4j3|2i1 




valid-key 


future use 


Octet 4 


md5-of-auth-key 


Octet 5 


Octet 6 


Octet- 


Octet 1 9 


Octet 20 


not used 


Octet ... 


Octet ... 


Octet 51 



Table 59: RLC_AUTHENTICATION_KEY_TRANSFER_ACK encoding 
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Semantics: 



Parameter 


O/M 


Description 


VALID-KEY 


M 


1 bits that equals 1 if the key is valid. 


MD5-OF-AUTH-KEY 


M 


Hash value of the AUTH-KEY, generated with the MD5 algorithm 



8 Service Primitives 

The following clauses define the service primitives exchanged between the RLC and CL layers within a H/2-HD. The 
additions to the RLC basic specification (TS 101 761-2 [2]) which are needed to meet the home environment 
requirements are documented. 

8.1 Primitive types 

Four primitive types may be used: 

- req (request), for a higher layer to request service from a lower layer; 

cnf (confirm), for the layer providing the service to confirm that the activity has been completed; 

- ind (indication), for a layer providing a service to notify the next higher layer of any specific service related 
activity; 

- rsp (response), for a layer to acknowledge receipt of an indication primitive from the next lower layer. 

The defined types for each category of primitive are shown as a list in curly brackets. 

NOTE: These primitives are defined only for the purpose of describing layer-to-layer interactions. The primitives 
are defined as an abstract list of parameters, and their concrete realization may vary between 
implementations. No formal testing of primitives is intended. The following primitive definitions have no 
normative significance. 

8.2 Common DLC C-SAP Primitives to Convergence Layer 

This subclause summarizes the common primitives between the convergence layer and the RLC layer whose realization 
is required for any supported CL. 
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Figure 32: Reference Model of protocol primitives 



The common primitives at the DLC C-SAP have a correspondence to a subset of the RLC primitives defined in 

TS 101 761-2 [2] and in the present document. The parameters used in the common primitives at the DLC C-SAP are 

equal to or a subset of the RLC parameters defined there. 

One DLC C-SAP common primitive may correspond to one of possibly several RLC primitives. It is the task of the RLC 
functions to control the relation between DLC C-SAP primitives and the RLC primitives. The RLC functions invoke the 
RLC primitives with appropriate parameters. (E.g. a request from the CL to set up 8 connections may result in 2 
subsequent connection setup sequences at the RLC level, each setting up 4 connections). 

At the CC the MAC ID is used to distinguish between different RLC instances. Each CC-capable WT therefore has to 
support different RLC instances. A basic WT, however, only needs one RLC. 

Realization of the following common DLC C-SAP primitives with their corresponding RLC primitives is necessary for 
allH/2-HDs: 
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Table 60: DLC and corresponding RLC primitives 



DLC C-SAP primitive 


RLC primitive 


DLC_Setup - { req, ind }; 


DUC_SETUP - { req, ind }; 
DM_SETUP - { req, ind }; 


DLC_CONNECT - { req, cnf, ind, rsp }; 


DUC_CONN - { req, cnf, ind, rsp }; 
DM_CONN - { req, cnf, ind, rsp }; 


i— \ ■ /—i i — \ i — it — ai~\i — r l i l 

DLC_RELEASE - { req, cnf, ind, rsp }; 


DUC_RELEASE - { req, cnf, ind, rsp }; 
DM_RELEASE - { req, cnf, ind, rsp }; 


DLO_MODIFY - { req, cnt, ind, rsp }; 


DUC_MODIFY - { req, cnt, ind, rsp }; 
UM_IVI(jL)lrY - { req, cnt, ind, rsp }, 


ni P Ml II TIPACiT iniM / ron r^nf inrl rcn I- 
ULL/ IVIUL 1 IL/MO 1 OVJIIN - \ Gill, lllu, Ibp j, 


Af>F rSRDI IP IOIM / ron nnf inrl rcn V 


DLC MULTICAST LEAVE - { req, ind }; 


ACF_GROUP_LEAVE - { req, cnf, ind, rsp }; 


DLC MULTICAST CONNECT - { req, cnf, ind, rsp }; 


DM_Multicast CONN - { req, cnf, ind, rsp }; 


DLC MULTICAST RELEASE - { req, cnf, ind, rsp }; 


DM_Multicast RELEASE - { req, cnf, ind, rsp }; 


DLC MULTICAST MODIFY -{ req, cnf, ind, rsp }; 


DM Multicast MODIFY - { req, cnf, ind, rsp }; 


DLC CL BROADCAST JOIN - { req, cnf, ind, rsp }; 


ACF_CL_BROADCAST_JOIN - {req, cnf, ind, rsp}; 


DLC_INFO_TRANSFER - { req, cnf, ind, rsp }; 


ACFJNFO - { req, cnf, ind, rsp }; 


CCH_start_cl_ho - { ind, rsp }; 


CCH_start_cl_ho - { ind, rsp }; 


CCH_start_cc - {ind, rsp}; 


CCH_start_cc - {ind, rsp}; 



NOTE: One DLC C-SAP primitive may correspond to one of possibly several RLC primitives. It is the task of the RLC 
functions (ACF and DCC) to control the relation between DLC C-SAP primitives and the RLC primitives. The 
RLC functions invoke the RLC primitives with appropriate parameters. 



8.3 Special DLC-C SAP Primitives to 1394 Convergence Layer 

If the 1394 CL is to be supported by the H/2 DLC home extension, the following 1394 CL specific DLC C-SAP 
primitives shall be realized in the concerned H/2-HDs. These two 1394-specific primitives are defined to imply that 
some special H/2 DLC services shall be provided to the 1394 CL locally in a H/2-HD. There is no peer-to-peer RLC 
message associated with them. 

1394 CL-specific DLC C-SAP primitive 
DLC_MAC_FRAME_START - { ind}; 

D LC_M AC_F RAM EN UMBER { ind}; 



The realization of DLC_MAC_FRAME_START is necessary to enable 1394 Cycle Clock propagation from a WCM 
(Wireless Cycle Master) to all other H/2-HDs, where the WCM can be any H/2-HD in the subnet. 

DLC_MAC_FRAME_START shall realize a time reference event, which shall be generated as a hardware impulse at 
the end of the 16 u,s broadcast burst preamble TS 101 475 [3]. The processing delay between the assertion of this 
impulse to the 1394 CL and the end of the broadcast burst preamble shall be a constant, which is known to the 1394 CL. 
After a calibration of the processing delay, DLC_MAC_FRAME_START is used as a reference event to trigger all H/2- 
HDs supporting 1394 CL to read and store the local 1394 CTR (Cycle Time Register) value at the same time. The stored 
1394 CTR value will be compared to that of the WCM, which is multicast in a LCH by the WCM to all other H/2 based 
1394 devices in each MAC frame, in order to correct the deviation to the WCM CTR (TS 101 493-3-1 and 
TS 101 493-3-2 see Bibliography)). 

NOTE: DLC_MAC_FRAME_START could be directly realized by a HW signal from the PHY layer. 

DLC_MAC_FRAME_NUMBER primitive contains the current MAC frame counter value obtained from the BCCH. It 
shall be sent to the IEEE 1394 CL in a way, that the current MAC frame counter value is available in the IEEE 1394 CL 
not later than the end of the FCCH phase. The current MAC frame counter value will be included into the CTR 
adjustment protocol PDU in TS 101 493-3-1 and TS 101 493-3-2 (see Bibliography). 



ETSI 



93 



ETSI TS 101 761-4 V1.1.1 (2000-06) 



Annex A (normative): 
PDU Types 

The basic WT and CC -capable columns indicate, whether the PDU is Mandatory or Optional to implement in basic WTs 
or CC-capable H/2-HDs. The PDU can be mandatory for both the sender and the receiver or the other peer only. If a 
PDU is mandatory for the sender, the sender shall be able to encode the PDU and send it at the correct time according to 
the present document. If the PDU is mandatory for the receiver, it shall be able to decode the PDU and perform the 
requested actions according to the present document. If the PDU is optional, the sender may not be able to encode or use 
it. If the PDU is optional the receiver may not be able to decode the PDU, but the receiver shall be able to send the 
corresponding RLC_NO_SUPPORT message TS 101 761-2 [2]. 



Table A.1 : HE LCH PDU messages 



LCH PDU type 


RLC message name 


Basic 
WT 


CC- 
capable 


(0000 0001) 1 


RLC CALIBRATION REPORT 


M 


M 


2 


RLC DM MC SETUP 


O 


M 


3 


RLC DM MC CONNECT 


O 


M 


4 


RLC DM MC CONNECT ACK 


O 


M 


5 


RLC DM MC CONNECT COMPLETE 


O 


M 


6 


RLC DM MC CONNECT COMPLETE ACK 





M 


7 


RLC DM MC RELEASE 





M 


8 


RLC DM MC RELEASE ACK 





M 


9 


RLC DM MC MODIFY 





M 


10 


RLC DM MC MODIFY ACK 





M 


11 


RLC TRANS CC DATA 




O 


12 


RLC AUTHENTICATION KEY REQUEST 


M 


M 


13 


RLC AUTHENTICATION KEY TRANSFER 


M 


M 











Table A.2: HE SCH PDU messages 



SCH PDU type 


RLC message name 


Basic 
WT 


CC- 
capable 


(0000 0001) 1 


RLC DM POWER CONTROL 


M 


M 


2 


RLC CALIBRATION MEASUREMENT TRIGGER 


M 


M 


3 


RLC CALIBRATION MEASUREMENT 


M 


M _j 


4 


RLC CALIBRATION REPORT TRIGGER 


M 


M 


5 


RLC SHORT CALIBRATION REPORT 


M 


M 


6 


RLC CALIBRATION LINKQUALITYMAP REQUEST 


M 


M 


7 


RLC CALIBRATION LINKQUALITYMAP 


M 


M 


8 


RLC CC HO REQUEST 




O 


9 


RLC CC HO REQUEST ACK 




O 


10 


RLC CC HO NOTIFY 


M 


M 


11 


RLC TRANS CC DATA ACK 




O 


12 


RLC START CC 




O 


13 


RLC START CC ACK 




O 


14 


RLC CC START OPERATION 


M 


M 


15 


RLC AUTHENTICATION KEY REQUEST ACK 


M 


M 


16 


RLC AUTHENTICATION KEY TRANSFER ACK 


M 


M 
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Annex B (normative): 
Parameter Types 



WT-TX-LEVEL::= TX-LEVEL 




ADJUST-TX::= ENUMERATED! 

no-adjust (0), 
m3dbm (1), 
moubm (2), 
m9dbm (3), 
ml2dbm (4), 
ml5dbm (5), 
ml8dbm (6), 
m21dbm (7), 
n3dbm (9) 

n^Hh ( 1 Ci\ 
pOUD \1\J), 

p9dbm (11), 
pl2dbm (12), 
pl5dbm (13), 
pl8dbm (14), 

p21dbm (15) } 




AGE-OF-RSS::= ENUMERATED { 
lastlOOms (0), 
Iast250ms (1), 
Iast500ms (2), 
lastl 000ms (3)} 




AUTH-KEY::= OCTET STRING(SIZE(0..46)) 




AUTH-KEY-LENGTH::= INTEGER(0..46) 




CAL-REPORT::= SEQUENCE { 
mac-id MAC-ID, 
rss2-value RSS2-VALUE } 




CAL-REPORT-LIST::= SEQUENCE 
(SIZE(0..23)) OF CAL-REPORT 




COMPLETE-REPORT::= SEQUENCE { 
mac-id MAC-ID, 
rss-report-list RSS-REPORT-LIST } 




COMPLETE-REPORT-LIST::= SEQUENCE OF 
COMPLETE-REPORT 




DATA::= OCTET STRING (SIZE(0..47)) 




DM-DUC-TYPE::= ENUMERATED { 
unicast (0), 

mutli-broadcast (1)} 


description 


EXT-IND::= ENUMERATED! 
data-end (0), 
data-continue (1)} 




FRAME-COUNT::= INTEGER(0..1 6) 




MAC-IDS::= SEQUENCE (SIZE(0..3)) OF 
MAC-ID 




MAP-EXT-IND::= ENUMERATED! 
map-end (0), 
map-continue (1)} 




MT-ID-NUMBER-LENGTH::=INTEGER(1 ..32) 




PIN-CODE::= OCTET STRING(SIZE(0..23)) 




PIN-CODE-LENGTH::= INTEGER(0..23) 




REP-BUF-STATUS::= ENUMERATED { 
reports-transmtted (0), 
reports-in-buffer (1)} 


description 


REPETITION-COUNTER::= INTEGER(0..4096) 
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REQUEST-TYPE::= ENUMERATED { 
whole-map (0), 
mac-id-map (1)} 




RR-FLAG::= ENUMERATED { 
receive-not-ready (0), 
receive-ready (1)} 




RSS2- VALUE 

::= INTEGER(0..63) 




RSS-REPORT::= SEQUENCE { 
mac-id MAC-ID, 
age-of-rss AGE-OF-RSS, 
rss2-value RSS2-VALUE } 




RSS-REPORT-LIST::= SEQUENCE OF 

RSS-REPORT 




SEQUENCE-NUMBER: := I NTEG E R(0. . 1 024) 




START-MAC-FRAME::= SEQUENCE { 
repetition-counter REPETITION- 
COUNTER, 

frame-count FRAME-COUNT } 




TRIGGER-TYPE::= ENUMERATED { 
all-wts (0), 
one-wt (1), 
one-wt (2), 
one-wt (3) } 


2 bits that indicate if one, two, three or all WTs 
are triggered: 

00 -» All WTs are triggered (no MAC-ID 
included) 

01 -> One WT is triggered 

1 -> Two WTs are triggered 

1 1 -> Three WTs are triggered 


VALID-KEY::= ENUMERATED! 
key-not-valid (0), 
key-valid (1)} 
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Annex C (normative): 
RLC TIMERS 

Management of RLC timers is described in TS 101 761-2 [2]. There are three different timers: 

• T_short; 

• T_medium; 

• T_long. 

The following new timers are defined in the present document: 



Table C.1 : H/2-HD Timers 



H/2-HD 


Value 


T_dm_mc_setup_wt 


T_short 


T_d m_mc_co n n ect_wt 


T short 


T_dm_mc_modify_req_wt 


T_short 


T dm mc release wt 


T short 


T_dm_mc_power_control 


TJong 


T_dm_mc_setup_cc 


T_short 


T dm mc connect cc 


T_short 


T_d m_mc_co n n ect_cm pt_cc 


T_short 


T_dm_mc_modify_cc 


T_short 


T_dm_mc_release_cc 


T short 


T_cc_ho_request_cc 


T_short 


T trans cc data cc 


6 msec 


T_start_cc_cc 


T short 


T_dm_mc_connect_ack_wt 


4 max_setup_t,me frames 


T_trigger_lifetime 


50 msec 
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Annex D (informative): 

Informative SDL FSMs concerning Power Control 

NOTE: The assumption in the model below is that the connection setup procedure between two WTs is split into 
connection setup between the CC and the first WT (WT1), and connection setup between the CC and the 
second WT (WT2). Only the connection setup with the second WT is represented since it does not depend 
on whether the connection was CC_initiated or WT_initated. 



/Connection^ 
Setup_to_WT2 



Connectivity 
Check 



RLC_DM_CONNECT 



R LC_DM_CQN N ECTA C K 



_CpN 



RG to WIT 



RG to WT2; 



SET(T1) 



=MAX_TRIES 



'Connectivity^, 
Check / 




False 




i:= 


-1 



RG_ 
to WT2 



SET(T1) 



True 



A r 




False 




i:= 


-1 



RG_ 
to WT1 



SET(T1) 



\ 

Disconnected 



True 



\ 

J V 



T1 



RLC_DM_CSNNECT_ 
COMPLETE/to_WT1 



RLC_DM_OQNNECT_ 
COMPLETE/tO WT2 



SET (T2) 



Disconnected) 



Wait_For_ 
First_Ack 



RLC_DM GONNECT_COMPLETE_ACK_ 
from WTr 



RLC_DM_GONNECT_COMPLETE_ACK_ 
from WT2^ 



T2 



Wait_For_ 
Second Ack 



Disconnected 



; Wait_For_ 
Second_Ack 









RLC DM CONNECT COMPLETE ACK 

from_WT?\ 


RLC DM CONNECT COMPLETE ACK 

from_WT?\ 


T2 



Connected I Disconnected 



Figure D.1 : Power Control - Connectivity Check - CC side 
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Connect on 
Setup of WT2 



[Connectivity 
Check 



Connectivity 
Check 







R LCD M (X) NNECTACK 


RG_ 
to J his. 


_yjT\ 


RG_ / 
to_peer_WT 


\ 










RLC_DM_Pi3WER_CONTROL_ 
to_peer WT/ 


SET(T1) 


/ 




I 



|WaitJor_PC. 
\ message 



Vait_for_PC 
message 



RLC_DM _POWER_CONTROL_ 
from_peer_WT 



RG_ 
to_peer 



SET(T1) 



jait_Connectioh_ 
Completeness 




RGJoJhislWT 



RLC_DM_PiaWER_CONTROL_ 

to_peer_WT/ 



/ait_Connectiorii_ 
Gompletejnesp 



RLCDMCONNECTCOMPLETE 



RLCJ3M POWER_CONTROL_ 
from_peer_VVT 



RLC DM CONNECT COMPLETE ACK 



Connected 



J 



RGJoJhislWT 



RLCJ0M_PQWER_CONTROL_ 
to_peer_WT/ 



Figure D.2: Power Control - Connectivity Check - WT side 
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Annex E (informative): 

SDL FSMs concerning Calibration 



NOTE: The following FSMs are only informative. Their aim is to explain the basic idea of how calibration and 
power control work, rather than to give algorithms ready to be implemented. 

Calibration - CC side 



Idle 



Start_Measurement 



Start_Repeirl 



RLC CALIBRATION MEASUREMENT TRIGGER RLC CALIBRATION REPORT TR 



T1 



T3 



IGGER 



Set(T1) 



Set (T1) 



Idle 



Nbr_Triggered:t 



easurementJTriggeredjWTs ^ meas. trigger message Rep3rt_triggered_WTs ~| rep. trigger message 



1 This is a parameter of the Nbr_Tiggered:== 1 This is a parameter of the 



Mbr Granted:=0 



Mbr Granted:=0 



Idle 



SET (T3) 



T3 expires at the beginning 
of the next mac frame 



SET(T3) 



T3 expires at the beginning 
of the next mac frame 



Measurement 



Report 



Figure E.1 : Calibration CC side - page 1 
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Measurement! 



k:=Granted WTs in last frame 



Nbr Granted:=Nbr Grknted+k 




Nbr_Trigi)ered:=Nbr_Tr ggered-k 



T1 



17 

Idle 







True 




SET (T3) 









T3 expires at the 
1 beginning 

of the next mac frame 



Start_Repdrt 



RLC_CALI BTj'ATION_REPORT_TRIGGER 



SET(T1) 



Nbr 
Reports 



■_Triggered:t 
Triggered J/VTs 



No Granted:=C 



SET (T3) 



Report 



T3 expires at the 
1 beginning 

of the next mac frame 



Figure E.2: Calibration CC side - page 2 



Report 















T3 


T1 


Start_Mea£urement 



k: =Gr ant ed_WTs_in Jastjram e 



Idle 



RLCCALIBfiATIONMEASUREMENTTRIGGER 



Nbr_Granted:=Nbr_Granted+k 



SET(T1) 



Nbr_Trig<jered:=Nbr_Triggered-k 



False 




r_Triggered>6- 



True 



SET (T3) 



Nbr_Triggered:t 
Measurement_Triggered_WTs 



Nbr_Granted:=() 



SET (T3) 



Idle 



Measurement 



Figure E.3: Calibration CC side - page 3 
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Calibration - WT side 



Idle 



RLC CALIBRATION MEASUREMENT TRIGGER RLC CALIBRATION REPORT TRIGGER 



RG 



SET (T4) 



Measurement 



SET (T5) 



Report 



Figure E.4: Calibration WT side - page 1 



(Measurement 



RLC_CAL^RATION_MEASUREMf NT TRIGGER 



SET (T4) 



T4 



RLC CALIBRATION REPORT TRIGGER 



RG 



Idle 



This trigger is for TRIGGER ED_MACID WT 



SET(T5) 



Report 



-iThis RG is for GRANTEDMACID WT 



True 



(TRIGGERED_MACID=WT_MACID) 

< AND > — 

(GRANTED MACftJ=WT_MACID) 



False 



RLC CALIBRATION MEASUREMENT True 



Measu 
of 



TRIGGEREDMA CID 
GRANTED^MACID 



ment_and 
oaLRSSJa'ple 



Measurement 



pdate_ 



Measurement 



False 



Measurement: 



Figure E.5: Calibration WT side - page 2 
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Report 



RLC_CALtt3RATIOM REPORTTR GGER 



SET (T5) 



T5 



Idle 



RG 



nThis trigger is for TRIGG ERED_MACID WT 



RLCCALIwRATIONMEASUREMENTTRIGGER 



SET (T4) 



Measurement 



iThis RG isfor GRANTED MAC ID WT 



True 



(TRIGGERED^-MACID=WT_MACID) 
AND 

(GRANTED JMC+D=WT_MAC ID) 



False 



TRIGGERE DMACID 



RLC CALIBRATION REPORT 



True 



Update, 



GRANTED MACID 



of local RS!> table 



Report 



Report 



False 



Report 



Figure E.6: Calibration WT side - page 3 
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Annex F (informative): 

Specification of the CC Probing Process in SDL 

The dynamic CC Selection has to prevent different CC -capable devices from becoming CC at the same time. The 
collision resolution mechanism is realized by the CC Probing and Frequency Scan processes that are defined in 
subclause 6.7. Both processes are described by a SDL specification which is depicted in Figure F.l to Figure F.4 and 
documented within this annex. 
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Process RLC_Dynamic_CC_Selection 




TIMER 
TIMER 
TIMER 
TIMER 
TIMER 
TIMER 



Probing_Period_TIMER; |\^ 
Probing_Frame_TIMER; 
Freq_Scan_TIMER; 
TransmTIMER; 
Transm_End_TIMER; 
N ext_Freq_T I M E R ; 



1(4) 



DCL 

BeaconDURATION 

Start_Scan_TIME 

Beacon_Send_TIME 

F_P 

P 

T_SCAN 

T_FS 

Freq_No 

No_Of_Freq 

Period_COUNTER 

uniform 



DURATION := 0.000048, 

DURATION, 

DURATION, 
DURATION := 0.00025, 
DURATION :=0.1, 

DURATION := 0.001, 

DURATION := 0.001, 
INTEGER:= 1, 
INTEGER:= 19 , 

INTEGER:=0, 
UniformDistribution; 













Start Scan TIME:-draw random(uniform) * P 












Set(now + Start_Scan_TIME, Freq_Scan_TIMER) 












Set(now+P, Probing Period TIMER) 



















Set(now+F P, Probing Frame TIMER) 












Beacon Send TIME:-draw random(uniform) * F P 












Set(now+Beacon Send TIME, Transm TIMER) 



Probing 



Figure F.1 : CC Selection - Initialization 

For the CC Probing and Frequency Scan procedures several timers are needed. Figure F. 1 contains the declaration of 
these timers which are the timers for probing period and probing frame, a timer announcing the transmission of a beacon 
(Transm_TIMER), a timer indicating the beacon fully has been transferred (Transm_End_Timer), a timer announcing 
the start of the scan process (Freq_Scan_TIMER) and a timer indicating the change of the scan frequency 
(Next_Freq_TIMER) . 
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Within the declaration the CC selection parameters are also defined and initialized according to the reference values 
introduced in subclause 6.7.3.1. The first phase of the CC Probing process is the initialization of the probing period 
introduced by the Period connector. The second phase of the CC Probing is the initialization of the probing frame 
introduced by the Frame connector. 



Process RLC_Dynamic_CC_Selection 



I I 



Probing 



Transm TIMER 



/* CC/MT Selection Specification 7 



2(4) 



Beacon 



Back off 



Freq_Scan "TIMER 



Set(now+Beacon_DURATION, 
TransmEnd _TIMER) 



Set(now+(T_SCAN+T_FS), 
Next_Freq "TIMER) 



Freq_No := 1 



^end Beaco^ 



switchfreq 



Freq_Scan 



Probing 



Probing Period "TIMER 



Period_Counter:= 
Period Counter+1 



Probing_Frame _TIMER 






Period Counter>=10 



true 



^CJ3peratior j 



Figure F.2: CC Selection - Probing state 



In the state Probing several signals can be expected, see Figure F.2. A "Probing_Period_Timer" signal indicates the 
beginning of a new probing period, a P robing _Frame_TIMER signal indicates the beginning of a new probing frame 
(virtual frame, not identically to the MAC frame). The reception of a beacon signal from another CC -capable terminal 
induces the terminal to leave the probing process and to accept the other terminal as CC candidate. The Transm_TIMER 
signal is received if the next beacon has to be sent. In this case the timer Transm_End_TIMER is started. Another signal 
which can occur is the Freq_Scan_TIMER indicating the beginning of a new frequency scan period. The probing 
process is finished if the Period_COUNTER expires. In this case the terminal becomes a CC. 
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Process RLC_Dynamic_CC_Selection 



Send Beaco 



Probing_Frame_TIMER 



3(4) 



/* CC/MT Selection Specification 7 



V ^aitJorBeac^ n 



Transm End TIMER 



Probing 



Transm End TIMER 



Beacon SendJTIME := draw random(uniform) * 

(2*F_P-Beacon_Send_TIME-Beacon_Duration) 



Set(now+Beacon_Send_TIME, TransmTIMER) 



Set(now+F_P, Probing_Frame _TIMER) 



Probing 



Figure F.3: CC Probing Process - Sending of a Beacon 



The probing process resides in the state Send_Beacon (Figure F.3) after the transmission of the beacon has been 
initiated by sending the beacon signal. If the beacon (CC Probing BCCH) overlaps into the next CC Probing Frame the 
P robing _Frame_TIMER signal is received and the process changes to a state Wait _Jor_Beacon in which the 
Transm_End_TIMER signal is expected. After the beacon has fully been sent (Transm_End_TIMER occurs) the sending 
time of the next beacon is calculated due to the overlap. 

The process changes back to the Probing state after the CC Probing BCCH has been fully sent. 
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Process RLC_Dynamic_CC_Selection 



I I 



Freq_Scan 
I 



4(4) 



/* CC/MT Selection Specification 7 



"K 



Beacon 



Probing_Period_TIMER 



'ait for Sea: 



false 




Next_Freq_TIMER 




Next_Freq_TIMER 



Back off 



Freq_No = No_Of_Freq 



false 



Perj^Counte?>=ia 
^^^^ true 

^ 



Freq_No = 
No_Of_Freq 



false 



Set(now+(T_SCAN+T_FS), Next_Freq_TIM E R) 



C_Operatio 



Freq_No := Freq_No + 1 



switchfreq 



Start_Scan_TIME := (2*P- 

(Start_Scan_TIME+(T_SCAN+T_FS)*No_of_Freq)) 
*draw_random(uniform) 



Setfnow + Start_Scan_TIME, Freq_Scan_TIMER) 



Pori 



Set(now+P, Probing_Period_TIMER) 



3riod_Counter = 
iod Counter -1 




Figure F.4: CC Probing Process - Frequency Scan 
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The frequency scan (Figure F.4) is started periodically whereby the start time is determined by random. The start time of 
the last frequency scan has been stored in the variable Start_Scan_TIME. To generate the start time of the next scanning 
period it has to be evaluated if the scanning period overlaps into the following probing period. In this case the 
Probing_Period_TIMER is received during the scanning period. The process changes to the Wait _Jor_Scan state. The 
scan procedure finishes equaly with a non-overlapping scan process. Afterwards the starting time of the next frequency 
scanning is calculated. The process is then continued at the probing frame initialization which is symbolized by the 
"Frame" connector. If a beacon signal is received the terminal leaves the probing process and accepts the other terminal 
as CC candidate. The receipt of a Next_Freq_TIMER signal within the scan procedure (state Freq_Scan or 
Wait _for_Scan) induces the process to change the operating frequency after the scanning duration T_SCAN. After all 19 
frequencies have been scanned the frequency scan is finished. It is not allowed to scan the frequency channels in order. 
The index Freq_No shall be mapped randomly onto the different usable frequency channels. The receipt of a 
Transm_TIMER indicating the start of beacon transmission is ignored during the scan procedure. 
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Annex G (informative): 

Specification of the CC Responsibility Handover Process in 
SDL 

In this annex the SDL specification for the CC Responsibility Handover is presented. The primitive initiating the CC 
Handover called CCH_cc_ho_request_req is received in the Associated state within the current CC (Figure G.l). Upon 
reception of the primitive the RLC_CC_HO_REQUEST PDU is sent to all WTs in the subnet and the CC changes to the 
state Central_Controller_Handover_Requested. In this state the RLC_CC_HO_REQUEST_ACK PDU is expected. If 
this PDU comes in, the CCH_cc_ho_request_cnf primitive is sent to the RLC environment. Afterwards a 
RLC_CC_HO_NOTIFY PDU is sent to all WTs. This is represented in the SDL diagram by a loop from 
MaxMacId to 0. If the signal has been sent to all WT MAC Ids the CCH_start_cl_ho_ind primitive is sent to all CLs and 
the CC goes into the state RLC_Stopped. 



PROCESS TYPE PTCC 



1(4) 



L A 



/* CC specific Specification */ 



DCL H\ 
count_mac INTEGER := MaxMacId, 
retransCounter INTEGER := MaxRetransmissions 



TIMER 
T cc ho 



req_ccT] 



SSOCIATECj 



Ce(itral_ControliW_ 
Har\dover_Requeeted 



CCHcc 
request_rd 



RLC_CCbKJ_ 
REQUEST\ACK 



|CC HO failed, 
' try another candidate 



RLC_CC 
REQUEST 



CCH_cc_hd 
request_cnf 



SET (T_cc_ho_rec _cc) 



RLC_CC 
NOTIFY 



=— ion DL RBCH 



CedtraLControliW 
Handover_RequeBted 



CCH starL^ho_ind 



RESE :T(T_cc_ho_rc q_cc 




RLC_ 
Stopped 



Celntral_ControliW_ 
Handover_RequeEted 



^SSOCIATECj 



lj Indication to CL 



Figure G.1 : CC Responsibility Handover - SDL specification of CC, page 1 

In the state RLC_stopped only the CC Handover procedure goes on at RLC level. The CC waits to receive the primitive 
CCH_start_cl_ho_rsp from the environment. After reception of this primitive the CC first starts to release all 
connections in CM of all WTs (see Figure G.2). If all connections in CM are released, the CC goes into the state 
Wait_for_ho_start. 
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PROCESS TYPE PTCC 



2(4) 



/* CC specific Specification 



IK [TIMER K 
I tiReleaselndTl 
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CCH_start^L_ ho_rsp 




RLC_RELEASE 

(dlccjdJisO 
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SET(\I 



ow+MaxAckTime, 
tiReleaselnd) 



iOnly DL/UL 
"Connections 



TRUE 



Wait_for_ 
ho start 



pQFUL'and DL 
"! Connections 
! released 



' Release_ 
i Initiated 














RLC Release 
(dlccjdjisti 


_ACK 


1 ~7 

tiReleaselqp 



count_mac := 
<:ount_mac - 1 



Mr 



Figure G.2: CC Responsibility Handover - SDL specification of CC, page 2 

In the state Wait_for_ho_start, the CCH_start_cc_req primitive is expected. If it comes in, the data transfer procedure is 
started (Figure G.3). For the data transfer a Go-Back-N ARQ protocol is applied. The CC knows how many 
RLC_CC_TRANS_CC_DATA PDUs are necessary to transmit all data to the CC -candidate. This number of PDUs is 
stored in the parameter pduToSend. The variable count_pduToSend in Figure 3 gives the number of PDUs that still have 
to be sent in the course of the procedure. At the beginning of the data transfer count_pduToSend is set to the value 
pduToSend. In each frame a certain number of RLC_TRANS_CC_DATA PDUs is transmitted in one packet train. How 
many PDUs are transmitted in a row is out of the scope of the present document. This is why the implementation of the 
function calcOptPduInARow is left open in Figure 3. Depending on how many PDUs still have to be send and probably 
also on the current traffic load the function calcOptPduInARow determines the value of the variable optPduInARow. 
Then the optPduInARow number of PDUs is transmitted by the loop that is controlled by the variable count_pduInRow. 
With each transmitted PDU the sequence number sn is incremented by 1 . If the PDU is the last PDU of the whole data 
transfer (count_pduInRow=l and count_pduToSend=optPduInARow), then the ext_ind field is set to (false). 
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If all PDUs of the packet train have been transmitted, the CC sets a timer for the acknowledgement and goes to the state 
Data_Send. In this state either the RLC_TRANS_CC_DATA_ACK arrives or the timer runs out. In case the 
RLC_TRANS_CC_DATA_ACK has arrived, the CC checks whether the RR_flag included in the PDU is true or false. 
If the RR_flag is false, the CC retransmits from the signalled snAck number on (this is done by setting sn=snAck). If the 
RR_flag is true, this means that all PDUs up to snAck have been correctly received. In this case the CC just sets the 
count_pduToSend parameter to the new value. It does not retransmit PDUs from snAck+1 on, but continues with 
transmission of PDU sn (sn is unchanged). A special case occurs if snAck is equal to 0. This indicates that the last 
RLC_TRANS_CC_DATA PDU of the whole procedure has been correctly received by the CC -candidate and that the 
CC can change to the state CC_Start_Initiated. 

In case the timer for the acknowledgement (T_trans_cc_data_cc) runs out, the CC retransmits the last optPduInARow 
PDUs (this is done by setting sn=sn-optPduInARow). 
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PROCESS TYPE PTCC 
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cfc J nt_pduToSen<p 
pduToSent - 
snAck +1 



sn := 
snAck; 
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Figure G.3: CC Responsibility Handover - SDL specification of CC, page 3 

In the state CC_Start_Initiated the RLC_START_CC_ACK PDU is expected from the CC-candidate (Figure G.4). If 
this PDU arrives, the CC sends the CCH_start_cc_cnf primitive to the RLC environment, reables its RLC and becomes a 
normal WT. 
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PROCESS TYPE PTCC 
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Figure G.4: CC Responsibility Handover - SDL specification of CC, page 4 

The SDL specification of CC Handover on the WT side of a H/2-HD (resp. on MT side in the basic SDL model) is 
divided in two parts. The first part in Figure G.5, Figure G.6 and Figure G.7concerns a WT that is selected as CC- 
candidate. The second part in Figure G.8 refers to all other WTs in the subnet. 

InFi gure G.5 the CC-candidate receives the RLC_CC_HO_REQUEST PDU in the Associated state. Upon reception the 
candidate generates a CCH_cc_ho_request_ind primitive that is sent to the RLC environment and the candidate changes 
to the CC_Handover_Indicated state. In this state the CC-candidate waits for the response primitive of the RLC 
environment to send an RLC_CC_HO_REQUEST_ACK to the CC. 
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PROCESS TYPE PTWT 



1(4) 



/* CC_Candidate specific Specification 
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fc_Handover\ 
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Figure G.5: CC Responsibility Handover - SDL specification of CC-candidate WT, page 1 

The CC-candidate is now in the state CC_Handover_Acknowledged. In this state the RLC_RELEASE PDUs sent by the 
CC are received (see Figure G.6 left corner). They are indicated to the CL with an appropriate primitive and in the state 
Release_Indicated_Cand the CC-candidate waits for a response primitive of the CL. If the response is received, the 
candidate changes to the state Wait_For_CC_Data. 

NOTE: The CC-candidate is a regular WT and may therefore also have ongoing CM connections that have to be 
released. 

In the state Wait_For_CC_Data either a RLC_TRANS_CC_DATA PDU sent by the CC is received, or the 
acknowledgement timer tiAcklnd runs out. This timer is not specified but it shall have a value less than 2 ms, to 
guarantee that at least one acknowledgement is sent per frame. All PDUs received within one frame are certainly 
contained in the same packet train. Therefore the inter-arrival time in between RLC_TRANS_CC_DATA PDUs of the 
same frame is very short. Due to this fact, the tiAcklnd timer could even have a much shorter value than 2 ms. If in a 
short time after a PDU arrival, no further PDU is recognized, this probably means that the PDU has been the last 
RLC_TRANS_CC_DATA PDU in the frame and an acknowledgement should be generated. 

If a RLC_TRANS_CC_DATA PDU arrives, first of all the tiAcklnd timer of the previous PDU is stopped. In case the 
received PDU is the expected one (snAck=sn-l) and not the last one (ext_ind=TRUE), a new tiAcklnd timer is started. 
In all other cases the acknowledgement is directly sent and therefore no timer is needed. One of these other cases is that 
the received PDU is not the expected one (snAck£sn-l). If this occurs a negative acknowledgement is generated 
(RR_flag=FALSE). A last case consists of the received PDU being the last RLC_TRANS_CC_DATA PDU of the 
whole CC Handover procedure (ext_ind=0). In this case a positive acknowledgement is sent to the CC with the snAck 
value set to 0. A snAck value of indicates to the CC that the data transfer has been successfully completed. 
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Figure G.6: CC Responsibility Handover - SDL specification of CC-candidate WT, page 2 

In the state Data_Send the CC-candidate waits for the RLC_START_CC PDU from the CC (Figure G.7). Upon 
reception of the PDU a CCH_start_cc_ind is sent to the environment. The environment responds with a 
CCH_start_cc_rsp while the CC-candidate RLC layer is in the state CC_Start_indicated. If the RLC receives the 
response of the environment it sends a RLC_START_CC_ACK PDU to the old CC and starts CC operation at the 
requested time. Furthermore a RLC_CC_START_OPERATION is sent out in broadcast mode to inform all WTs about 
the take over of CC functionality. 
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PROCESS TYPE PTWT 
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I* WT specific Specification 
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Figure G.7: CC Responsibility Handover - SDL specification of CC-candidate WT, page 3 

Figure G.8 finally gives an overview over the CC Handover specific processes inside a WT that is not a CC-candidate. 
After the reception of the RLC_CC_HO_NOTIFY PDU the WT goes into the state RLC_Stopped_MT. In this state the 
WT waits for the RLC_RELEASE requests for its CM connections. After indication and response to/from the CL, the 
WT changes to the state Connections_Released_MT. If no RLC_RELEASE requests are received, e.g. in the case where 
the WT only maintains DM connections, the WT directly changes to the state Connections_Released_MT after the timer 
tiNoReleases has run out. In the state Connections_Released_MT the WT receives the 
RLC_CC_START_OPERATION message and goes back to its basic state Associated. 
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Figure G.8: CC Responsibility Handover - SDL specification of WT 
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Annex H (informative): 

Example of valid Reed-Solomon word 

The following RS word is built from 4 consecutive PDUs. These PDUs are normal LCH, hence the PDU-type is set to 
00. The sync field is inverted for the first PDU. The other bits of the first octet are set to zero. The contents of the other 
octets of the PDUs are explained in the table below. 





PDU#1 


PDU#2 


PDU#3 


PDU#4 


PDU type 


00 


00 


00 


00 


Sync field 


11 


00 


00 


00 


Octet #i 
value 
(from i=2 to 
50) 


I 


50+i 


100+i 


150+i 



The following RS word has been obtained from these 4 PDUs payload with padding 39 04oytes in front of the 200 
payload bytes and applying the RS(239,255). The redundancy is in bold. 
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nni I4ah 

PDU#1 


PDU#2 


nni 14*0 

PDU#3 


nni i-uA 

PDU#4 


Octet #1 


48 


o 


o 


o 


Octet #2 


2 


52 


102 


152 


Octet #3 


3 


53 


103 


153 


Octet #4 


4 


54 


104 


154 


Octet #5 


5 


55 


105 


155 


Octet #6 


6 


56 


106 


156 


Octet #7 


7 


57 


107 


157 


Octet #8 


8 


58 


108 


158 


Octet #9 


9 


59 


109 


159 


Octet #1 


10 


60 


110 


160 


Octet #1 1 


11 


61 


111 


161 


Octet #1 2 


12 


62 


112 


162 


Octet #1 3 


13 


63 


113 


163 


Octet #1 4 


14 


64 


114 


164 


Octet #1 5 


15 


65 


115 


165 


Octet #1 6 


16 


66 


116 


166 


Octet #1 7 


17 


67 


117 


167 


Octet #1 8 


18 


68 


118 


168 


Octet #1 9 


19 


69 


119 


169 


Octet #20 


20 


70 


120 


170 


Octet #21 


21 


71 


121 


171 


Octet #22 


22 


72 


122 


172 


Octet #23 


23 


73 


123 


173 


Octet #24 


24 


74 


124 


174 


Octet #25 


25 


75 


125 


175 


Octet #26 


26 


76 


126 


176 


Octet #27 


27 


77 


127 


177 


Octet #28 


28 


78 


128 


178 


Octet #29 


29 


79 


129 


179 


Octet #30 


30 


80 


130 


180 


Octet #31 


31 


81 


131 


181 


Octet #32 


32 


82 


132 


182 


Octet #33 


33 


83 


133 


183 


Octet #34 


34 


84 


134 


184 


Octet #35 


35 


85 


135 


185 


Octet #36 


36 


86 


136 


186 


Octet #37 


37 


87 


137 


187 


Octet #38 


38 


88 


138 


188 


Octet #39 


39 


89 


139 


189 


Octet #40 


40 


90 


140 


190 


Octet #41 


41 


91 


141 


191 


Octet #42 


42 


92 


142 


192 


Octet #43 


43 


93 


143 


193 


Octet #44 


44 


94 


144 


194 


Octet #45 


45 


95 


145 


195 


Octet #46 


46 


96 


146 


196 


Octet #47 


47 


97 


147 


197 


Octet #48 


48 


98 


148 


198 


Octet #49 


49 


99 


149 


199 


Octet #50 


50 


100 


150 


200 


Octet #51 


6 


76 


209 


27 


Octet #52 


125 


158 


101 


163 
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PDU#1 


PDU#2 


PDU#3 


PDU#4 


Octet #53 


87 


1 


115 


101 


Octet #54 


179 


92 


15 


61 
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